Framing UX concepts for your team (part 2): IA, design patterns, affordances
tl;dr — simplify the jargon so you can name and talk about UX issues together.
Today’s goal is to document how I’ve framed UX concepts to be more digestible for xfn teams.
I want to create products that make lives better. I’m listening to Sunshine by Keane today.
This is the second part in a series about framing UX concepts. See the first post for USER-related concepts like CUJs, personas, and use cases.
This post will focus on DESIGN-related concepts when working through a specific UI/UX design solution.
Shouldn’t design terminology be left to the designers?
No. In my decade of work experience, I’ve only seen problems arise when teams and stakeholders are not aligned on the lingo. This is especially frustrating when someone is asking questions or suggesting changes, and you keep talking past each other. This is the same for product and engineering terminology — what do you mean by a strategy vs a roadmap? How do you define a requirement? What is an API? A server?— just get everyone on the same page when you see confusion arising. It doesn’t really matter HOW you use the terminology as long as you all are on the same page about what it means. If you’re a PM, this is especially important since you’re often the glue between these different functions.
When would these design-related concepts matter?
If you’ve run into any of these situations below, then maybe it’s a good time to align on these concepts so you can more effectively collaborate with UX to talk about and solve problems:
- The way information is laid out and navigated in your product feels wonky and unintuitive. There’s likely an issue with the “information architecture” or “information hierarchy” in your app.
- There are similar actions that a user needs to take in several different places in your product, but it currently looks and feels confusing and inconsistent. This is probably a situation where you want to establish a consistent “design pattern” that users can learn once and easily recognize and reapply when needed.
- Your team is frequently divided on how to balance between competing product goals, like enabling the product to be hyper-configurable and flexible while also keeping it simple, or appealing to the tech-savvy power users while also making it easy to use for your grandma. In this situation, it may help to align your team around some core “product design principles.” these principles serve as guideposts to help you make decisions when there is not a clear right answer.
- The latest design for a flow is missing some important things that the user needs to be able to understand and do. In this case, the design is likely missing some “affordances” that are required to satisfy user needs.
You don’t have to actually use these design terms, but the team should be aware of and understand the concepts so you can talk about them together. Sometimes, just being able to “name” the topic or issue helps to make progress towards resolution.
So how best to frame these concepts for my product/eng teams?
As usual, my disclaimer is that this is what has worked for me and it may not be the “right” way to do it, but I found the following to be the simplest way to get folks on the same page.
The guidance for my recommendation: keep it simple and use plain English when you can.
1. Design principles
This is an important foundation to how you design a cohesive product. The goal is to set principles that help you make decisions in ambiguous situations. Think about the different dimensions that you could position the product in, and the different extremes that you could take (consumer vs enterprise, simple vs powerful, opinionated vs flexible). Put them on a line and mark the point on the scale for where you want the product to be, but avoid the middle. Make sure both ends of the spectrum are valuable and realistic (don’t do: confusing vs simple, obviously you’re not trying to make a confusing product). IMO, this is the UX equivalent to a product “mission.”
2. Conceptual model
This is how I refer to the thinking behind the “objects” that a user has to learn and understand in the product. This is a gross simplification of how designers use this term, but I think it’s simpler to understand. Think about any digital software product you use today — there’s generally one or two “primary objects” that are the focus and “container” that most other features work off. For example, if you use Google Docs, the primary object there is a document, and then you can share them, add images/tables to it, format it, etc. If you use Gmail, you might argue there’s several key concepts, probably starting with emails, an email editor, then threads, then labels. When designing a new product, you have to think about what are the “objects” you introduce to the user and how to keep it from getting too complicated. Even better, if you can make your conceptual model match an existing mental model that your users have, it significantly reduces the learning curve. For further reading, check out Alana Brajdic’s great post on Understanding mental and conceptual models in product design.
3. Layout & navigation
This covers information architecture/hierarchy and generally how information is organized and grouped together at appropriate levels for users to consume and navigate the app. When designed well, the layout and navigation should complement the conceptual model, so it feels natural and intuitive to navigate and manage the objects and their information in the product. This concept helps cover issues with what information is shown when, where, and how users discover and consume it. Try to leverage Gestalt principles to help organize information more intuitively.
4. Actions & Controls
Use this concept to talk about how users should actually interact and modify objects in your product and what options you give them. What happens when they click something? How does the object and UI change or give visual feedback so the user knows what happened? What buttons and menus do you give them to make these changes? When designing these [inter]actions and controls, try to keep consistent with the conceptual model, keep controls close to the objects they affect, and reuse existing established patterns if possible. If you see a need for the same actions and controls and outcomes in multiple places, then it’s time to establish some consistency with a “design pattern.” For a deep dive, I recommend reading The Design of Everday Things by Don Norman. Also, Taras Bakusevych’s post on Selection controls is a great example of the nuances involved in designing actions and controls.
5. Requirements
Finally, this last key concept is one that will be familiar with most product managers and designers. I recommend focusing on “functional requirements,” similar to what you might write for a user story in a backlog or what might show up in a PRD. I think this is a really important concept to align on with UX because it helps clarify rules and responsibilities between PM/UX, establishes a common ground between how product/research work connects to UI/UX design, and when properly defined can enable more creative solutions.
For folks who are familiar with the term “affordance”, you’ll see the similarities. An “affordance” refers to the possibility of an action on an object. For example, a chair affords sitting, a shower has affordances to turn on/off and control temp/flow of water, the Gmail UI has affordances that let a user create, send, view, and delete emails and lots of other actions.
When defining and talking about requirements, focus on what functionality the user wants/needs, not on the specific implementation. If the PM is writing requirements like “User can see a blue share button in the top app title bar,” I would say they’re crossing into UX responsibilities and you’re asking for an eventual conflict to arise — a requirement should look more like “User needs to share the document with their contacts.” Requirements can sometimes lean too heavily into technical implementation too, especially for more technical developer-facing products like APIs. Writing good clear requirements will be a post for another day though. :)
By being less specific about the implementation, it reduces the chance that your requirements will get out of date/need to change, and also enables the team to explore more solutions together.
There’s a lot in this post, but I think the above 5 key concepts are the most important ones to make sure my team and I are on the same page about when working through design problems for products.
If we’re get aligned on these 5 concepts, then the team can more easily discuss the key parts to where, what, when, how, and why a design solves for a user need.
