“Research.” What a stale word, bringing back memories of 6-page high school papers about topics we rarely cared about while we wrote a half-assed bibliography in MLA format. Research just sounds boring, like I’m going to waste hours with my nose buried in a textbook. But, in the wonderful world of web design, research is actually really, really cool. So cool, in fact, that I prefer to call it “Discovery.” Discovery is much more exciting, like the Discovery Zone playplaces of our youth. Discovery means a sense of curiosity, wonderment, and in a sense—fun. And that’s how I view the Discovery portion of a project.
Discovery is an important phase of any project, one that shouldn’t be overlooked. It informs the rest of the decisions we will make throughout the rest of our engagement. And by decisions, I mean all of our decisions. Too often the discovery work falls onto one person whether that is a content strategist, a designer, or a project manager. But the thing is, the research isn’t some side task that we do for the sake of saying we did it. It’s really valuable to understanding both the business and user goals of the project. We need to understand where our strategy originated in order to fully comprehend how we can extend it. And, in order to understand our strategy’s origin, we need to all have a helping hand in crafting it.
What We’re Discovering
Our discovery phase should include some key data that we’re hoping to get: client (stakeholder) input, user input, and competitive analysis. During discovery, we want to include as many stakeholders on the client side as we can. In this preliminary stage it’s important to make sure everyone on the team who has an impact on the redesign has felt that his or her opinions were heard and valued.
Creating the content and questions for these different stakeholder interviews should involve all team members so that we can gather the different perspectives. Developers should interview any technical stakeholders, so they can dig deeper into their technical needs. Designers should interview their creative and marketing team about their current brand, and so on and so forth. This creates a sense of camaraderie not only between us and the client’s team, but also amongst our own team. The discovery phase is something we are all invested in—right at the beginning of the project! It gets us started off on the right foot, actively discussing the goals together and making sure all our voices are involved.
We also know that listening to our users is important to helping us make the experience better for them. We want to get to know them as people so that we make empathetic decisions in the future. And of course, we want to check out the competition and see what they’ve done that works and doesn’t work (and how we can help differentiate our client).
Different Types of Goals Will Yield Different Types of Research
It’s important to write out the goals we hope to achieve with each type of research we conduct. For example: “in our stakeholder interviews, we want to gather common goals and priorities amongst our stakeholders while also highlighting their differences to reach a consensus.” But knowing why we should gather information, the data we want to gather, and the ways we want to gather that data is only half the battle. The other half is actually conducting it.
Gathering Data for CodePen
We’ve recently been working with CodePen on their redesign. The discovery we conducted has been imperative to the decisions we will make so that they not only reflect what their team wants, but also what their incredible community of users want. Since the audience is primarily web developers—who understand how research can improve products—we’ve been able to have a lot of fun talking to them in our research. The different goals and priorities that we heard from their team directly influenced the data that we wanted to gather from the users. Once the goals were established, we were able to determine the different types of research we needed to do.
We sat down and talked to many users across the world, simply to get to know them and how they used the product. The themes we pulled from these interviews directly informed the personas we created—which now serve as a discussion point during feedback as we move forward with design. In addition to these one-on-one interviews, we also sent out a mass survey asking the community for their opinions. The key element of the survey was the number—if an overwhelming amount of users requested or hated a specific feature, it’s worth considering in our effort. We also wanted to observe CodePen in action, so we did some in-person ethnographic research—watching some users walk us through how they commonly use CodePen. We could then see first hand the areas that were most important to these users’ experiences and also the weird workarounds they had for certain hiccups on the current site.
Sharing Your Discoveries
Kevin Hoffman recently visited our office to give a Maker Series workshop on good meetings, and he focused a lot on kickoff meetings. In my experience, kickoff meetings are invaluable to creating a successful working relationship between us and the client. Sitting in a room, face to face, with the client makes both of us have a high level of empathy for one another. We can picture Mike from Marketing sitting there, begging for a way to make the CMS image input smoother for his team or Julie from IT lighting up at the idea of integrating Sass. And likewise, their team is more likely to listen to our opinions, knowing that we are real people on the other side of Basecamp, too.
Not only are kickoffs great for fostering relationships, they’re also the best showcase of the findings from the Discovery phase. This might seem odd to many, since kickoff meetings are often what you think of as the very first meetings with a client, but Kevin and others recommend doing a lot more legwork on a project to have valuable insights to share once a later kickoff meeting occurs. Since we have the attention of many people, where most internal weekly meetings are kept smaller, we’re able to share with them the distilled core business elements we found that many stakeholders in the room will be interested to hear. This is a primary reason to let these meetings occur later, when you have more to share. We have several hours to present and really dig through our findings, and leave the meeting energized that we have established the goals that we want.
These shared goals are somewhat rooted in stakeholders, somewhat rooted in users, somewhat rooted in our own experiences, but above all serve to make everyone’s communication and decisions for the project much stronger.
If you’re looking to discover (ha, see what I did there?) more about how to do this sort of research, Erika Hall’s Just Enough Research is an excellent resource!
