Recently, the Jetpack Design and Research team has implemented a regular day to talk to our users once per month. It’s a small step toward an important goal of better understanding what our users need, seeing and hearing first hand where they are frustrated, and learning how Jetpack can work better for them.
The relationship benefits both sides. Our customers enjoy a sneak preview of features coming down the roadmap, and are empowered to help shape the product’s future. And our design slash research team sees first hand, how our products perform with real folks using them.
The problem with user research
As anyone who has tried to work user research into a busy product development team’s workflow knows, you usually run into one or more of the following challenges:
- Timing: Getting work in front of users before you get dug in on a concept, as you iterate and before you build.
- Internal adoption: When primary stakeholders do not see the value in or do not place the proper weight on the information coming from the research.
- Publicizing: Making sure the information gets to everyone in your organization, that it doesn’t just get filed into a hefty but dusty folder marked “research.”
Enter the evergreen research project
The question of timing:
Having user input throughout the design and development process is ideal, but this is challenging when you do not have a team fully dedicated to research. With our set schedule to talk with users, no matter where a project is in the product design cycle, we can always gather feedback and use it in the next step. Software is never done, and thus, neither is research.
Internal adoption
This 100% comes down to generating actionable insights that drive results. As researchers, we simply must show how research can directly and positively impact the experience our users have with our products. Takeaways must be tied to concrete actions.
A standing research day gives us an opportunity to dig deeper into more complicated core product issues and larger open questions in order to inform future product roadmap initiatives. We can test and refine our hypotheses so we know we are solving the right problems for users.
Publicizing
So how do we make sure to get the information to the right folks? Documentation is excellent, and we need that, but I’m also a big advocate of having representatives from all functional groups join user calls. Once you are on the research call, you are on the research team! The more teammates directly experience the information, the more it will get shared.
Challenging assumptions
One of the most significant advantages of speaking to users with a regular cadence is that it continually challenges internal assumptions. Research is the practice of listening and letting go. Research is being willing to let go of assumptions when they conflict with user truths. Users change, and their needs change, so we must continually refresh the information we use to apply to our design work.
Building Empathy
This one is cool: when you have a team continually connecting with their customers, you find that they start to become internal ambassadors for the users, helping to weave the user’s voice into product and design conversations throughout the entire product design process.
Designers start referring to users by first names and putting “faces” to interfaces when designing. In sprint planning meetings, developers start echoing back what they heard in user interviews. By proxy, users become active members of the design, development, and product teams.
Actionable Insights
The “Duh” Moment
Sometimes you get lucky, and a user points out for something the team just flat out missed. It’s that facepalm, “of course” moment when everyone shakes their head and says, “Yeah, we need to do that.” These insights are funny in that, as veteran designers, we certainly don’t like to see when we miss something obvious, but it will inevitably happen when we are “heads down” on a meaty project. User research is the cure. These are the little golden nuts we can scurry away with and immediately address.
The “Huh” Moment
These insights are not particularly groundbreaking, but they are surprising. For example, a self-proclaimed “non-technical” user recently explained to me why she wants to see the technical details of security errors on her site (even though she may not know what they mean). She even showed me a composition notebook of how she tracks issues and why she does not trust buttons that say things like “fix-all” (we had just shown her a beautiful mockup with a big “fix-all” button). In subsequent interviews with other users, we saw this sentiment echoed. How does this affect our design approach?
The good news is that the users who wanted the detailed information quickly found it—they just did not use the button). Our job going forward is twofold: 1.) to make sure we are providing enough information for this segment of users; and 2.) resisting the temptation to reduce design noise at the expense of negatively impacting their confidence and comfort level.
The “ah ha!”moment
Unless you are in the very early product ideation phase, the big “eureka” moments are a little less common than the steady accumulation of small insights. Ah-ha moments do happen, but the trick to getting more of them is knowing which threads to explore further. You usually start to see a theme forming across many users, leading to a collective ah-ha rather than a lightning strike in a single interview. The more deeply you understand your users’ daily workflow, the more likely you are to have these eureka moments.
We’d love to talk with you
If you are a Jetpack customer and would like to get involved in our ongoing research, visit the Jetpack Research Blog and sign up to join us for a call!
Automattic Design