I was participating in a UI brainstorming meeting recently with four other designers and a product manager. The meeting was focused on “solving” the UI for a mobile app. I was struck by how many times I’ve been in this type of meeting — where the team hopes to emerge with the design for the app — but no particular process is in place to ensure it can happen.
Here are 5 techniques for making UI design meetings actually succeed.
1. Know exactly what features you are designing for
You can’t move a group conversation forward if you don’t have shared knowledge of the features you are going to provide. And no individual designer can possibly create a holistic UI framework without knowing all the pieces that need to be supported.
If there isn’t a well-defined list of features that everyone is privy to, then it’s too easy to get bogged down in “are we doing that?” feature wrangling. Inevitably, there is tension between what the MVP should contain and what ultimately could be delivered. It is beneficial to have that ultimate picture in mind so you don’t end up ‘band-aiding‘ additions at some later point. But if you don’t have justification that users would be interested in a specific feature, or engineering can’t possibly build it, or the marketplace doesn’t warrant your product containing it (because it’s peripheral to your offering and someone else is already doing it better), let that feature go. It is just creating noise.
What to do: Identify what your product is going to offer. Make a list, or better yet, construct a taxonomy — where larger features that encompass sub-features are clearly spelled out in an outline format. Then make sure that product management and engineering have signed off on it and that the designers are familiar with it before you head into a design meeting.
2. Sketch more, talk less
“What if it was like this: <lengthy verbal explanation>?” How many minutes (hours!) of design time have been spent listening to one person go on about how it might be? And what is everyone else visualizing as that wordy description unfolds? Undoubtedly, no one is picturing the same thing. The lengthy description is often met with no feedback; then the describer says he’ll mock it up later, and little forward progress is made.
Without something to look at, a user interface idea can’t be critiqued, expanded on, or evaluated. Would you attempt to describe a car dashboard’s layout or the organization of buttons on a toaster oven in words? It’s unlikely. And those products are likely to be simpler than the UI of the software product you are designing.
What to do: Have paper handy and sketch something rough — for yourself to explore later, or to share with others on the spot. Let others sketch their responses. Make sure paper, pencil, and printouts of any existing designs are available to scribble on. Encourage everyone to draw, regardless of talent, because it will aid comprehension of his or her ideas. Visualization is key.
3. Always provide a rationale
Don’t create endless variations without explaining the reasoning behind them. Why is one direction better or worse than the other? What does one accomplish that the other doesn’t?
In the meeting I was in, five wireframe variations of one functional area were shown — some were distinct directions, others were mashups of those distinct directions — but none of them were presented with “this meets users’ need to x, while this one emphasizes the y feature but at the expense of feature z”. What was the rationale for creating any one of those designs? Without any rationale, it’s difficult for others to evaluate a design’s effectiveness or offer suggestions for improvement.
What to do: Convey the thought process that went into creating each design direction. Explain what it does well and what it could do better, preferably from the point of what a user is trying to accomplish (which is grounded in the list of features you constructed — see item 1 — that were derived from user research you hopefully conducted). A design brought into a working meeting isn’t finished, so when it is presented, explain what’s not-so-done about it. And present it in a way that people can easily sketch their responses to it (or on it).
4. Remember that UIs are dynamic and conversational
UI design is different from other types of visual design. Rather than solely communicating information, UI screens are part of a back-and-forth conversation with the user. This conversation needs to be sensible as it unfolds over time. Each screen contains both information and functionality, and needs to respond in a comprehensible way to the user’s input.
Creating a UI is like storytelling — we’ve certainly all heard that before. Unfortunately, the individual screen wireframes I saw the other day were plucked from several different story lines. There was no throughline — they didn’t make sense as a sequence. The screens depicted a variety of states in several functional areas, and the actual content on each screen varied widely. They didn’t represent a coherent conversation between the app and the user.
Consequently, it was impossible to understand the UI conversation. This hampered both the design team’s internal communication and each team member’s ability to experience how the design would feel to a user. Those screens could have just as easily been part of a single, coherent story line, incorporating consistent and carefully selected content to move through the interactive states.
When a coherent conversation / story line is created, the wireframes can be used within the design team, but also by the design team to clearly explain ideas to other company stakeholders, or as the backbone for a mockup to test with potential customers. UI designers end up doing less work this way, because the wireframes serve many different needs.
What to do: Construct “vignettes” — short sequences of screens that storyboard compelling and realistic interactions, each using consistent exemplary data. Focus on maintaining story continuity. Build a quick prototype using a tool such as InVision or simply print the screens from your Sketch document and look through them in order, focusing on one at a time. These types of design artifacts provide everyone with the ability to assess the entire design through a user’s eyes.
5. Don’t forget about time
If your app is successful, your user is going to do something today, based on something she did yesterday, and hopefully she’ll do something again in a few hours or days or weeks. How will your app deal with history, with the present, with the future? The design team must think about the representation of a user’s data at all points in time.
An app’s content changes and grows as a user interacts with it, which means the design team must think about vastly different quantities of data. If you only explore one time slice, you’re not really constructing a comprehensive UI framework.
What to do: Carefully consider early use, mid-use, and one year down the road — to ensure the design scales. Then cycle back and think about the first use. First use is a brief timeframe, but it’s critical to user acceptance and it’s typically fairly unique. First use is where concepts are introduced, where the app’s value must be made apparent — even if no user data yet exists! — and where set up work typically needs to occur. If your users don’t ever get on board, they are not going to be there for anything else.