Lately, I’ve watched Disney’s Moana about 600 times (shoutout to my fellow toddler parents). In case you haven’t seen it, it’s the story of plucky teenager Moana and her journey across the ocean to save her people. Along the way, she encounters antagonist Tamatoa, a villainous giant crab that collects shiny objects from across the sea and displays his extensive collection atop his shell.
Tamatoa actually reminds me of my team at Indeed, the Job Seeker Accelerator—not for his vanity or hunger for human flesh, but for his collector’s mentality. Job Seeker Accelerator is an internal UX consultancy that partners with Indeed’s product teams to solve the messiest job seeker problems. Because we’re taking on complex spaces that cross many teams, we often start our design projects by amassing and arranging a ton of information.
UX practitioners are problem solvers, but we only add real value when we’re solving the right ones. Background research is critical to knowing what those are. Here’s how my team gathers and organizes the information we need to make a project a success.
Forage for context
Much like a giant crab scouring the ocean floor, the Accelerator team starts projects by gathering knowledge. We want to know everything that’s been done or planned at Indeed to solve a problem and what might’ve gotten in the way of solving it before. We lovingly refer to each other as “trash animals” because of how much we relish the sifting and collection process.
This foraging is, above all, an acknowledgment that we are surrounded by subject-matter experts and excellent user experience professionals at Indeed who have almost certainly thought about the problems we’re tackling (and documented those thoughts). When we imagine all the collective hours it took to put together the materials we find, absorbing them can feel like hitting the fast-forward button on a project. Foraging honors the time, effort, and creativity of those who came before us.
More context leads to better design, and in almost every company there’s plenty of context to go around. I encourage you to think about how you forage in your own work and use what’s come before as a springboard for your creative processes:
- Dig deep. We often start with our internal UX research library and company wiki. We talk to as many people as possible, take careful notes of these conversations, and ask who else we should talk to. We use what we learn from our reading and stakeholder conversations to do keyword searches of Figma and Slack to learn more.
- Go broad. It’s helpful at this stage to learn as much as you can. Try to worry less about whether it will end up being relevant. You don’t want to artificially constrain yourself this early in the process. You’ll frame and trim during your sensemaking processes.
- Structure. As you dig, you’ll want someplace to put your information, especially since it can be hard to know early on what’s essential and what isn’t. Channel your inner Marie Kondo and apply structure to what you find as you go, perhaps by organizing information by themes or user groups. Add short summaries of what you learned while it’s fresh in your mind.
- Absolve yourself from having to know everything. Your goal is to learn as much as possible, not to know everything (an impossible dream). Trust that if you collaborate well with partners, anything important you miss will come out in due time.
Unlike Tamatoa, our team doesn’t stop at simply collecting. We want to bring sense and order to what we’ve learned.
Make sense of the research
So now you’ve got piles of information. Your next job is to understand what people should pay attention to out of this mess.
I won’t talk about synthesis methods because the one you choose will be highly dependent on the information you’ve gathered (and “cool synthesis method guide” feels like its own article ). But here are some guideposts:
- Remain tethered. The knowledge ocean can be a deep and scary place. It’s helpful to have a tether, which for my team is often a project brief with a stated mission—usually, a business- or customer-related reason you need to solve this problem right now. Refer to it often to keep from floating away.
- Watch out for holes. In any good gathering process, you’ll encounter other problems that are only tangentially related to your goal. Some of these will be real, painful, and will need to be solved, but trying to solve them now can derail you. It’s helpful to have a place to put these so you can ensure they get addressed and you can remain focused on your why. I recommend creating a collection document where you can list information you’ll return to and act on later.
Once you understand the story of everything you’ve learned, you need to summarize the information and share this picture with others in a way that will be easy for them to consume—without asking that they spend the hours that you’ve taken to get here.
—
Is this article helpful? Subscribe to get occasional emails with new stories like it.
—
Tell the story
When my team worked on an incredibly complex user problem with years of organizational context, we reached a point where we needed to bring our core project group together to ideate. To create alignment and a shared understanding of what we had learned, I made an exploration guide in a shared doc that included lots of screenshots and diagrams. Here are a few things to consider no matter what storytelling medium you choose:
- Set expectations up front. Think of your internal audience as your user. What should they expect to get out of what you’re sharing? What should they not expect to get out of it? We frequently include a “What this is” section in our documents and decks to really be clear about what a person can expect from what they read. I especially like to ask, “if a person stumbled upon this file without all the context, what would I want them to know to get started?” In a world where folks are working remotely, collaborating asynchronously, and sharing digitally, this context is especially important.
- Retell the user story. You’d be surprised how often this gets missed. Frame the problem for your audience precisely as the user sees it, how it makes them feel, and related information that might influence these feelings. Keep this clear of all the things you’ve learned about why the problem exists in the first place. Save the messy business context that explains why the problem ended up the way it did for later in your story.
- Add layers, like an onion. You’re catering to internal users with different amounts of time and investment. Include optional ways to go deeper into nuanced areas of the problem that aren’t critical to the overall understanding but could be interesting for people with a lot of investment.
- Invite builds and corrections. Accept that there are likely things you’ve missed. Deliberately invite others to add to the narrative through comments, edits, and corrections.
- Include your asks. After a person has all this shared understanding, what do you want them to do with it? Clearly lay out what next steps you’d like them to take.
First, we rediscover, connect, and listen; then, we synthesize; and finally, we use storytelling to make plain to others what we think it all means.
Tell us about your collections
Like a friendly, unthreatening Tamatoa, the Job Seeker Accelerator collects shiny objects from across the vast sea of Indeed information. We strive to make fresh sense of all that valuable info, shed light on underlit spaces, and help solve thorny problems. We’re always interested in learning from other intrepid explorers.
How are you foraging and synthesizing in your own work? Any particular collection, organization, or storytelling secrets that have been vital for you as you gear up to design something big? Find Indeed Design on Twitter or LinkedIn, and let us know.
Happy collecting!
—
Special shoutout to my Accelerator trash animals 🦝 who helped me put these examples together.
