Without a solid intention, a designed solution will have unclear decisions, shallow exploration, and mediocre quality. Describing the shared design intent gives a solid foundation for the whole product team to work together on.
☕ Design intent clarifies what a design aims to achieve
This might be familiar to some design leaders. One of the designers starts a new project. As the design progresses, you review the work. “So what are you trying to do here?” “We need to create this table for that list of items.” “No, I meant what’s the goal? How will this fit the user’s journey?” “…”. And this goes on - since the designer is unclear about what they are trying to do (besides marking requirements done), it’s also unclear whether they’ve finished. Which results in too many back and forths over supposed to be final designs.
At the core of this and similar situations is the lack of clear intentions. Both on the project level - the product team is unclear about what they set out to do or at least they don’t have clarity. Also within the design process intention clarity can be lacking. As every design decision should have a reason, but since the designer is unclear about what they are trying to achieve, decisions are vague and don’t have a clear foundation or clear target. Results are shallow, with lots of talk about surface-level changes, but disconnected from the wider context. If there is a little push, the whole solution topples and falls apart. Which ultimately leads to mediocre design.
Unfortunately, the lack of clear intentions goes beyond the problems on the design’s level. Since there is no unifying idea that is shared by the whole team, the overall UX will also suffer. Research insights will be overlooked, engineers make trade-offs that contradict what the designer wanted to do, and marketing and support will be misaligned with what the product is capable of.
Before design starts, the problem to be solved should be clearly understood - by the designer and by the whole team. Often at the starting point of a project, just a few vague ideas are known or some scattered research materials, or some numbers not moving up enough. When designing, the tactical aspect of diving into Figma is not the most valuable, but the relation between understanding and creating should be the primary target for the designers.
Design is not art and not something the designer does on their own in Figma. Design should be the rendering of intent, that is the shared intent by the whole product team (and anybody else contributing). So what’s intent exactly? It’s the goal we are pursuing within the context. Great products also need the intent to be a shared intent, a common understanding in the team of what everyone is doing together, as the design does not happen in isolation. Discovery is not only about discovering the solutions, but also discovering the problem, and what the team will do about it, articulating the shared intent.
I’ve used two ways of defining intent in the past, by creating briefs and by working with hypotheses. Briefs work well as a high-level description that summarizes research done and kicks off the design process. But they are not easily broken down into smaller pieces and are connected to detailed design decisions, so they are best used for check-ins and milestones. Hypotheses on the other hand fit well to be used within the process, as they can be broken down into smaller pieces.
Design briefs for designers working in product teams differ from what a creative agency would want to have. They don’t need to extensively document project meta. Instead, a brief should describe the goals of the project and what should be the focus - this also declares what is not the focus. Something that worked well for me in the past is to have four sections in the brief:
- Goals or main hypothesis
- Personas or jobs
- Scenarios or flows
- Design principles
This keeps the brief lightweight and flexible enough to have it at the top of the mind of everyone in the project, and also makes it easy to iterate on.
Hypothesis-driven design works especially well if the wider team also uses hypotheses. Even without that, keeping track of “what am I trying to do”-“why am I trying to do this”-“what do I expect this will do” is a useful mindset to have while designing. Articulating intent as a hypothesis also sets up testing and validation, and the potential impact will be also much clearer - this changes the conversation about what the design is supposed to do.
Shared is an important aspect of having clear intentions. It’s not enough if the designer knows what they are trying to do and how design decisions are connected to the goals. The rest of the team also needs to be on board. Since the designer is looking for a foundation of design work, getting the team to articulate the shared intent often falls on the designer. A good way to make sure there are no misunderstandings is to talk, a better way is to work through and prepare it together. Workshops typically work well.
Articulating shared intent is not easy, and sometimes might be the hardest part of a project. Intents might need a lot of back and forth between product team members, and they get clearer as they get articulated. Part of this process is also understanding past user research done (“So we intend users to…” “Who are these users?”) and business goals (“.. increase adoption” “What’s adoption in this context?”).
Once a clear intent is articulated, it can be used in a few ways immediately. Shared before discussions with stakeholders clarifies “are we working on the right thing”. They help to give context and focus feedback before design critiques. In team discussions, they make sure the team is still aligned on the common goals.
For design leaders, seeing intentions across projects makes the background of projects and the alignment across designers and product teams more visible.
This is a post from my newsletter, 9am26, subscribe here:
🍪 Things to snack on
Jared Spool wrote extensively about intent:
- Design is the Rendering of Intent describes how design teams and product orgs should think about their process. I like this formulation a lot as it also clarifies what designers should be focused on. The article gives a few examples of how user behavior and the team’s goals to change it are connected.
- The Magical Short-Form Creative Brief is a description of intent I’ve used often in the past. By describing what the design is set out to achieve in a simple format, the whole team will be watching the same TV channel. This brief has four sections: Project objective, Key personas, Key scenarios, and Key principles. The article also gives a few examples of how the brief should be used in team meetings and rituals.
- LiRPPS: Lightweight, Research-Based Principles, Personas, and Scenarios part 1 and part 2: One disadvantage of having a brief is the perceived difficulty of creating it. The article outlines how the brief can be created based on user research done in a few hours with some workshop exercises.
Design critiques are key to checking if a design is on the right path to solving the goals it set out to reach. Adam Connor writes about how to set this goal in Setting the Foundation for Meaningful Critiques: Goals, Principles, Personas and Scenarios. Since design critique is an analysis, the critique group needs to have a good understanding of what to evaluate against. Personas and scenarios provide background information, lenses, and context for the design. Goals and principles describe what the design tries to achieve. Sharing these with the critique group results in a deeper and more useful critique.
Jake Burghardt has a series about working with research insights. In Mapping existing research into design briefs and workflows — to get more done with insights he describes how research can inform design direction, by adding insights into design briefs. This brings researchers into the design process at the right time and increases the impact of researchers.
I liked the thoughts of Caio Braga about working with intent versus working without in Rendering intentionality. He argues that many designers and design teams focus on rendering requests, that is designing features. By not having clear intentions, there is no focus on user needs, and while the product expands, ultimately issues won’t get resolved. Designers should care about the impact of their work and not the work itself.
Andrew Duckworth describes how to use hypothesis to describe design intent in Hypothesis driven design. A lot of designers already work on having an idea and afterward designing it to see if the idea works - so having a hypothesis and testing it, but they rarely write it down. Once it’s a statement written down, it becomes an articulation of intent. Good hypotheses are testable and verifiable, adding a framework around guiding the designer’s thinking. The article also gives a few examples how this idea can be used in practice.
Comments