A simple exercise to guide an information-first approach to design
And how it worked when my team tried it
How many hours of your life have you spent on YouTube, grasping to learn a tool or product from a stranger?
If anyone feels the need to do that, the product team failed at its job.
People shouldn’t struggle to learn how to navigate a site or use a product. That’s easier said than done, of course. But just because something’s complex doesn’t mean we should treat learning curves as inevitable. And we definitely shouldn’t rely on people who post in a forum or create grassroots tutorial videos to bring people over that curve.
User experience designers often address challenges like this, but in the weeds of flows, site maps, and vaguely-defined blocks of content, information is usually treated like an accessory or component to this thing we call an experience. In reality, it should act as the core.
To elevate the importance of information, you need to begin with it — in all of its precision — in the design process.
Why information-first?
Information-first design means that before you hash out anything else, you decide what to communicate to people. The term “content-first” gets thrown around a lot. While these two concepts overlap, a content-first approach requires a more fleshed out point of view on what form or structure the content takes.
The term “content” can send a signal to people that it’s not their job to care. In product design, information viscerally feels important to everyone.
In terms of how other flavors of design fit in, things like hierarchy, aesthetics, and flow make or break an experience. But how they navigate through something is only as important as what they learn along the way.
An information-first approach democratizes the design process from the ground floor. Anyone can and should come into a conversation about information. You don’t need know how to write, design, or code to bring value.
The exercise a.k.a. information prioritization grid a.k.a. the good stuff
Alright, enough lollygagging. Let’s break down this exercise.
When to make an information prioritization grid: Whenever you plan to bring something new to your users, whether that be a feature, policy, opportunity, or thing to consume.
Who to bring in: “Everyone” is an easy answer. But who is everyone? In the first round of this exercise, I’d start with your immediate design/development team and a couple of subject matter experts. That way, you discuss feasibility and accuracy of information sooner rather than later.
From there, you can share it with executive stakeholders, people whose roles tangentially relate, and general smart cookies who know how to poke holes in things.
How to do the exercise, step-by-step:
- Write your defined audience(s) at the top of a sheet of paper or document.
- Make a three-column diagram, and label those columns Definitely, Probably, and Maybe.
- Ask everyone to take sticky notes or your team’s digital equivalent (We like MURAL).
- Silently write down pieces of information your defined audience(s) definitely need to know, probably need to know, and may need to know. Sort accordingly.
- Delete exact duplicates. However, don’t delete similar pieces of information. Precision matters. For example, when my team did this, one sticky note read “the purpose of this course” and another read “the outcomes of this course.” We kept both because purpose speaks more to the “why,” while outcomes speak more to the “what.”
Note: Still feel free to group similar pieces of information. This can help organize thoughts and drive conversation. Those themes may even inform the way you structure your content later. But don’t let those themes obscure what lies under them.
6. Discuss every piece of information as a team. Move them across columns and add new ones when it’s relevant.
7. Once everyone in the room (or on the call) agrees on the state of the grid, pass it around to people who stayed out of the original brainstorm session. Either let them edit the document directly, or collect feedback from them in another format.
My team’s situation: the good, the bad, the mundane, and the important
About a month before my team launched a course about design thinking and AI, we realized there was no clean or coherent way to squeeze that information on our landing page; we had to add a new page.
We were bound to a tight deadline, which meant we had to use an existing design template. This worked to our advantage in that we didn’t get caught up in limitless amounts of choice, but it also meant we had to compromise our intentions a bit.
For example, to start the course, people had to log in. We couldn’t link them to the log in page in our first iteration (because technology), so we wrote the instructions in plain text to start.
Super exciting stuff, I know. But I bring it up to highlight that while functionality can make an experience better, people need information regardless of if there’s a fancy interaction attached to it.
As a content designer, building out the structure and flow of content felt easier than usual; my team and I agreed on what was and wasn’t important before I went off in a corner to write copy.
Meanwhile, our visual designer didn’t need to wait on me for ~the perfect words~. We could work in tandem while we gave focused attention to our respective responsibilities. That’s what a grasp on the same informational anchors affords you.
Not just for static pages
You might think, “This sounds like a basic-ass design. Not relevant to my work, which is anything but basic!”
Yes, my team’s application was pretty basic. But the hypothetical version of you in my mind is wrong about the second part. You could also use it to define when or how to reveal depth of information, too.
For example, people definitely need to know all the information on the main interface; they probably need to know the information in a guided product tour or a tool tip; and they maybe need to know the information in technical documentation.
I won’t promise that this specific exercise can map out the intricacies of a complicated, dense web of the information that is your product ecosystem. I will die on the hill of its core principles: Think first and foremost about information and do so as a team.
Believe it or not, these three columns are a good place to start.
Amanda Booth (@wordswithamanda) is a Content Designer at IBM. She’s based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
