In product teams, designers and researchers are the voices of users. During my time at Meta and Google, I have seen various opportunities for design and research to help teams be more user-centric throughout the product development cycle. Below are 5 of my favourite fun and inclusive ways designers can help product teams be more user-centric. 1: When brainstorming, don’t just write on post-its, draw user stories together. Workshops with our cross-functional teams make the ideation process inclusive and a bonding exercise. To take them further, look for opportunities to encourage participants to draw their ideas, instead of only writing them out on post-its. A picture speaks louder than a thousand words, not only for the audience but also for the person who draws the picture. The focus of the group drawings is less on designing screens (there’s value in doing that too, but less relevant for building user-centric mindsets), but on imagining and then drawing the scenarios for how a potential user may encounter the features they are proposing. If other non-design functions are hesitant to draw, you can remind them that “no idea is a bad idea”, or “no drawing is bad drawing”. Drawing quality or accuracy is irrelevant here. The main goal is to get into the users’ shoes and create a human story. To make it easier to get started, provide a storyboarding template, like this one: Provide an example of how it can be filled out, like this one: If there’s time after drawing, have people verbally narrate their stories! This will help further internalize the stories for them, and sense check if the solutions they are proposing actually solve the user problems. I know sometimes it’s hard enough to just get an hour with cross-functional members to just write post-ins. Drawing will take too much time. But trust me, I’ve seen these help team members build much deeper empathy for users, and really come together as a team to think from users’ points of view. Give it a try! 2: When presenting design visions, present them as a story instead of a feature list. As designers, we all know it’s important to stay user-centric. However, when working closely with product and engineering functions that operate a lot more on feature and task bases, it’s too easy for us to think feature by feature, task by task. As a result, I have seen many design visions presented with themes and then features. But visions by definition set the high-level directions for teams, and shouldn’t be the exact feature list teams should follow. So if visions are presented as features, teams can easily lose sight of the user problems, and the big picture and only focus on the exact features. So instead of presenting visions as a feature list, I encourage designers to always try to present visions with a user-centric story. Here’s an example structure for a vision deck: I’ve heard people say using a user story to present visions can feel cheesy. It might be, but it does work well in helping the audience understand the use cases quickly, and make sure they focus on the user needs and goals instead of the specific features. I have seen user story-based vision presentations work time after time. Doesn’t hurt to try next time when you are working on a vision. 3: When doing user research, invite the whole team to observe and share note-taking tasks amongst team members. At the companies I’ve worked at, designers don’t run user research by themselves. We almost always collaborate with user researchers to do them. Over the years, I have seen researchers take drastically different approaches when it comes to how much they try to involve the other functions when running user research. The two extremes are 1) researcher that involves the whole team throughout the process, and 2) researcher that consults the team but mostly does research separately from the team. While team culture and team member availability may dictate how user research may fit into the team, it’s always worth a try for user researchers to get other team members as involved in the process as possible. The tactical suggestion I want to make here is to invite engineers, product managers and other functions to observe research sessions and ask them to take turns taking notes. Instead of half-mindedly observing the sessions and getting one or two random takeaways, note-taking will help people pay much closer attention and evaluate more carefully before making conclusions about what the users are actually saying. 4: When the feature is almost done, do a walk-through of the end-to-end flow as a team. During the implementation phase, experiences are usually broken down into smaller features and tasks. When it’s close to the shipping time, it helps to step back and walk through the whole built journey together as a team. A walk-through session is a great way to bring the team together, click through the key flows, and call out problems. To do a product walk-through session, make sure you already have the key user flows defined before the session. During the session, assign a person to share their screen and click through the planned flow. Let people speak up when they see problems in the flow, and at the same time, assign a dedicated note taker who will record the problems mentioned. Doing a walk-through session brings the team back to the user at the end of the implementation process, and gets them to think about if the feature has indeed provided the expected values to the users. 5: [Bonus for fancy teams] When doing foundational field research, invite other functions to join. This is probably the funniest, but also the most costly in time and money. If there’s a budget to organize field research, invite other functions. Once your product team members step into the user’s space (their house, office, city etc), and hear them talk about their stories, they won’t be able to unsee or unhear them. Find ways to bring your product teams closer to the users. A cheaper alternative would bring a few users into your office. Your product teams will have a realization moment of ah, yeah I’m building for real people. Hope you will try some of the methods. Leave some comments to share your thoughts! 💬
