Color-Coded Product Design in Align
Written by: Joey Muething, Align Product Manager
Product design people: a total overhaul of a screen usually isn’t the answer. More often, it’s the tiny, insightful, empathetic design tweak that will provide the better ROI on user delight.
That’s probably not a thundering shock to most of you, but it bears saying out loud. Too often we can fall victim to the temptation to lock our team in a room for a few months and hope a magical user interface comes out the other end of the trench-run. Here’s a story to back up this point: a small decision the Align design team made that ended up having a big impact on user experience.
Background: in Align there are Huddles. These are meetings that teams within an organization belong to and participate in on a daily or weekly cadence. Someone can belong to one, several or no huddles, depending on their role in the organization. Users are encouraged to prepare their information in each huddle ahead of time, so that the rest of the team can review what you’re focusing on that day, even if you end up missing the meeting.
Although each Huddle has its own membership and purpose (e.g. customer support daily huddle), and the same topics might get discussed in different Huddles, sometimes the given topic can be 1) very specific to a given huddle; and 2) very sensitive, only to be seen by those in that Huddle. There’s the rub: when you’re rushing to get in your daily information across several Huddles in the morning, it’s easy to imagine someone losing their place and entering info where they shouldn’t.
And that’s, unsurprisingly, what we observed. Users were entering Huddle A info in Huddle B, leading to potentially embarrassing mixups. The user experience wasn’t giving a strong enough indicator of where you were in space.
Thus we found ourselves with an interesting design problem to tackle. Here’s a summary of the process we went through:
What Does the Data Say?
Like any good data-driven team, we looked at what usage analytics could tell us before rushing to define solutions. We’d very clearly heard the stories of users mixing up their Huddle information, and the pain that causes. But how many users might this potentially affect? How do we make sure we’re not falling victim to recency bias in our user feedback?
A quick query from one of our engineers produced this graphical summary of how many Huddles users manage at one time.
To summarize:
| 94.78% of users have 3 or fewer Huddles 90.66% of users have 2 or fewer Huddles 79.07% of users have 1 or fewer Huddles |
So a little under 5% of our users are juggling at least three Huddles at once. How did these statistics inform our decision?
To help prioritize feature changes, we tend to use the Severity-Frequency matrix seen below:
(Credit to Brandon Chu in The Black Box of Product Management for this graphic)
Based on the data we explored, we put this problem in the top-left quadrant. It only affects a small percentage of users, but when it does happen it’s BAD. We decided it wasn’t in need of a breakin fix, but slotted the work into our next sprint/release rotation.
Exploring the Solution Space
Once our team decided this was a problem worth solving, the next step was “how should we solve it?”
When our team contemplates potential designs like this, we make a conscious effort to avoid “implementation bias.” That is, we first shoot for breadth versus depth, exploring as many different design solutions as possible. In this way, we avoid fixating on any one solution too early, which would lead to the risk of optimizing towards a local maximum that in the end doesn’t adequately solve the original problem.
(Des Traynor and Bill Buxton do a great job of illustrating our breadth versus depth approach. Credit to them for the above graphic in a recent Des tweet.)
Here are some of the solutions we explored and why we decided against them:
- Force users to confirm that they entered the info in the correct Huddle, before letting them save. This seemed inelegant and too obtrusive. Also, in the end if the user is rushing through their data entry too quickly, they might just as easily blow through the confirmation without checking.
- Let teams choose and upload an icon to go with their meetings. Display the icon when entering information as a visual cue for users to remember what Huddle they’re in. While this was deemed a better solution than (1), we still decided against it. Building the icon upload feature would take more development time than we liked. There also was no guarantee teams would even use it, unless we forced them to do it, which seemed equally as burdensome to the user as (1).
Ultimately, the design we chose balanced effectiveness and user effort. We decided to lean on the design theory of Color Affordance, and have our solution flow from there.
Color Affordance Explained
First: Affordance? This is a term made popular in the design space by Don Norman in his book The Design of Everyday Things, but was actually first coined by psychologist James J. Gibson 10 years prior (fun fact). Norman ran with the original definition of an “object’s properties that show the possible actions users can take with it.” He then extended the concept into the digital space, honing in on the idea of an affordance being “perceivable action possibilities.”
In other words, the design itself should hint at what actions a user is able to perform. We’re all, consciously or not, well-versed in common affordances in web design. For example, clickable buttons tend to have well-defined borders and change shade when you hover over them. Our thought, then, was to give users hints of what Huddle they were in, based on a unique and constant color theme for that Huddle.
I’ll admit that we’re stretching the definition of affordance here a bit. We’re not talking about suggesting actions a user might take on an object; we’re providing a color-based cue on where a user is in space. But accurate or not, we started with this design concept and that led us to our solution.
Designing the Solution
Now that we had picked our solution, it was time to refine and get into specifics.
Topic: Where should the color be displayed, so that a user can quickly internalize the association between color and Huddle?
Answer: Color in the Huddle navigation, as well as each team member’s Info section, which is where the data entry occurs.
Topic: How should we handle the edge case of a user having many Huddles? (remember, the data showed us 95% of users have less than four).
Answer: Switch the design from a button-by-button selections to a dropdown menu.
Shipping and Refining The Solution
We released this feature towards the end of last year. Overall, we had a very positive reception to the design change. Anecdotally, we heard from several users that the subtle color hint went a long way in reducing possible data entry errors. I’ll freely admit that I’ve personally caught myself a few times putting information in the wrong Huddle, only to catch myself thanks to the color hint.
We collected initial user feedback and made some small design changes. We also have some further design improvements in mind that we’re thinking about running with.
Summary
Our team going through a deliberate, thorough design sprint allowed us to discover a solid, relatively easy-to-implement solution to a problem that was having a negative effect on some of our users. We used data-driven decision making and a proven design principle to quickly and confidently improve a core feature of our product.
Want to see if Huddles can help your team communicate better?
