A couple of weeks ago, we came up with a plan to build a "Guide-Driven Blog" together. This week, we'll start making it a reality by working on our initial User Experience (UX).
UX is one of those big terms that has a different definition for everyone. For me, it is the systematic process of identifying, researching, and empathizing with our target users' problems and then solving them via a usable interface.
Notice how there's nothing in there about design skills or artistic expression? In my experience, UX is more science than art. And that means we can all do it. In practice, this means that UX is about research, hypotheses, experimentation, and meeting users rather than coming up with incredible designs.
Don't get me wrong, if you can do both, then please continue to do so. But, for the rest of us, we can still deliver fantastic user experiences without artistic talent.
Now that we have a shared understanding of UX let's walk through how to deliver an excellent experience for our users.
Identifying the Problem
Fortunately, we've already identified our users' problem in step three of our product plan.
"Readers get to read content that is better formatted for their individual needs."
Now let's translate this problem into a testable hypothesis. While articulating a problem is useful, making it into a hypothesis makes it actionable. And that's what we need to keep moving forward.
So we hypothesize that "if readers visit a guide-driven blog then they will be able to find relevant content easier than a normal blog because the content is easier to search."
This hypothesis is something we can research further.
Researching Our Hypothesis
Research is always a little tricky. It's one of those things that everyone loves to pay lip-service to, but very few people do it. It takes time, it's hard to track down users, and most stakeholders aren't entirely onboard with it.
When I present conducting UX research to my colleagues, I often start with the cost of failure. If we spend tons of time and money developing this project and it fails, then we're going to be in a tough spot.
But, if we take the time up front to do some research, we increase our chance of building something that is aligned with our users' needs and thereby increase our chance of success. This approach has worked for me in the past, and I hope you can use it too.
Since we're building our own project, we don't have to worry too much about aligning stakeholders. So, let's get down to researching. First, we need to recruit some test subjects who closely resemble the end users of our project.
Recruiting Test Subjects
Recruiting test subject is not an easy feat. If you already have a product, you can reach out to your existing users. But, getting test subjects for a brand new project is hard.
Hopefully, you're building something that solves a personal need, and you've already talked with some folks about how they've experienced it too. These are excellent potential candidates that you can reach out to and try to interview.
If you don't know anyone who might fit, I recommend heading to social media and Craigslist to try and drum up some test subjects. If you can't find anyone there, you might want to reevaluate what you're building. Because if you can't reach your target market now, how will you reach them after you've spent a lot of time building something?
Now that we've gathered at least five test subjects who closely match our users, we can interview them to see if they're experiencing the problem we identified. To do that, we'll need a script.
Writing a Script
Taking the time to write a script is incredibly essential for two primary reasons. First, it keeps the interview focused, so we don't waste the interviewee's time. And second, asking all of the interviewees the same questions keeps our process consistent. If we asked all of them different questions, then our results wouldn't be beneficial.
Now coming up with a good script takes a bit of effort, but the rewards are worth it. When I ran my first interview, I didn't have a good script. I just described the problem and my solution for it and asked the interviewee if that sounded reasonable to them. I didn't get the insight I was looking for because I didn't ask my user the right questions.
Over time, I've picked up better questions to ask - especially from Ash Mayura. My current process is largely based on his, so I highly recommend that you check out his writings on the subject. With that said, our scripts should essentially break down into three sections.
The first part is about gleaning some of the interviewee's demographics like age, gender, job title, industry, etc. These details help us identify patterns and organize patterns we see in their responses. If all the salespeople say one thing and the software engineers say another, then you might have stumbled upon a different problem for each of these groups.
The second section is about setting the "problem context." We want to describe the problem to the interviewee in terms they can relate to so they can construct a mental model of the issue and recognize it in their own life. This typically involves telling a story to the interviewee and asking them if they identify with it and what other thoughts it brought to mind.
This part can generate some vague responses. But, the critical thing to remember is that we're looking for patterns. If 80% of the interviewees brought up the same pain point or situation, then you're on to something important and can continue to investigate that in further interviews.
Finally, we'll try to figure out how the customer is currently solving their problem in the last section of the interview. Asking them what they do now, if anything, is incredibly illuminating.
You might find out that they're solving their problem in a way you would never have thought about. Or, you could learn that they don't have a great solution and your idea could help them tremendously. This last step can undoubtedly generate some fantastic ideas for you to work on.
Validating The Hypothesis
Once you have at least five interviews under your belt, you should start to see if folks are resonating with the problem you're describing or if they don't care about it. If they're all asking when your solution will be ready, then your probably on the right track.
But, if it turns out they don't care, first, double-check your assumptions that you've recruited from the right user group. It could turn out that you presented the right problem to the wrong people.
If you're sure you interviewed the right people, focus in on what they did say is a problem. It could be that your original hypothesis is slightly off the mark, but you can pivot to a different problem to solve.
If it turns out they don't have anything for you to pivot to, then you can either do another round of interviews to be sure. Or, you can feel confident that you haven't wasted a bunch of time building something people didn't want.
Now that our hypothesis has been validated, it's time to turn our research into actionable user flows.
User Flows
Now I know what you're thinking, "Nick, we already mapped out the user flows in our project plan!" And you're right, we certainly did. But, now that we've done the research, we can revisit these user flows to see how far off our initial assumptions were about our solution.
Writing out goals and assumptions before testing them is such an important, and frequently forgotten, step in validating an idea. If we don't have something to compare our results to, then how will we know how right or wrong our initial plans were?
By comparing our existing user flows to the results we generated from our research, we're trying to find the intersection of what users are experiencing and our vision for a solution.
With this in mind, we can revisit our existing flows and check that they're still relevant. If not, we can update them with the findings from our research.
The Wrap-Up
While this post, titled "UX," might seem like something we do at the beginning of a project and then forget about. In reality, it is a never-ending process. As long as we're building something for other people, we need to be validating our assumptions to ensure that we're building the right thing.
Of course, the one big exception to this rule is if you're making something for yourself. If that's the case, you could skip these steps and get right to building your idea. Just remember that if you do try and bring it to a broader audience, a little UX research will go a long way towards your success.
Now that we have our user flows, we can start building our project by putting together some wireframes. As always, feel free to ask me any questions on Twitter. And until next time, happy researching!