A walkthrough of my design process
One of the challenges of being a generalist at a startup is that I tackle a lot of problems that are badly defined and not, strictly speaking, a product design problem. I've found the best way to solve these issues is to follow the UCD model.
The first hurdle is to formulate a problem statement. A big part of this process is having a conversation with stakeholders about why they want to build something. But I’m also proactive in finding customer problems.
Here’s a screenshot of the Trello board that I kept at Sense. Every time I had a user research session, I recorded what we talked about and, added color coding, to easily identify themes that I heard over and over again. Every time I was in a discussion with the team, I could recite off the top of my head specific examples of when I encountered customers with the same problem. I was able to ask multiple customers about the issue before the conversation even began.
The next step is to validate if my assumptions about what the problem is are correct. Typically, this means having additional discussions with customers to see if they also have the same problems. However, you can’t just ask them outright if something is a problem: you have to be careful about how you articulate your question. For example, if you ask someone how often they go to the gym, they're likely to say, “I go three times a week!” But if you ask them when the last time was that they went to the gym, they might say, “Oh, I think three weeks ago.”
This is a screenshot that I pulled from one of these customer calls where I wanted to validate a problem. This is a completely non-existent piece of software that I made up in Sketch just for this call. I assumed that the problem was that when they met a brand new candidate who applied for a job, they didn't know how qualified the applicant was for the position. So, I showed them a new feature we were working on to help them assess the “score” of new candidates in their inbox.
Turns out I was wrong. I made some incorrect assumptions about what the root problem was. And without this step of validating my assumption, we would have spent several months building out a feature that didn’t solve the root problem. Instead, we were able to change course and build something better, without wasting any engineering time.
Once we’ve validated the problem, the next step is to design out the solution. This includes helping the PM write a spec for the project, onboarding engineers to get their input and spot problems, and creating wireframes, mockups, etc.
Above is a collection of screenshots from when I was building out the Sense iOS app. There was a lot of discussion on the team about what features should be included in the MVP. If we added too few, it would feel useless. Too many and development time would creep up. All the previous work we'd done in identifying and validating the problem made the discussions during this stage productive. When we were discussing which features to include, the conversation wasn't “I feel like we need to have X” but instead “If we’re building this to solve X, we need this feature” or “This feature isn’t important if our goal is to solve X”
The last part of the UCD cycle is to validate your work. Did it solve the problem? One of the biggest challenges of this step is that you can’t rely on A/B testing at an early stage startup. Because you have so few users early on, to get any statistical significance, your tests would have to run for months before you got a result. So instead you again rely on qualitative analysis from user research.
This is a one-pager we printed for a conference when we were testing some new copy and designs for our marketing. A lot of the qualitative validation of this process came from our sales team at conferences. How did the questions you were asked at the booth change? Did you run into the same problems as last year? Did you run into any new problems? It’s not the most scientific process, but even the simplest follow-up can help you course correct. At this conference, for example, we inadvertently introduced a new problem from some confusing copy that we didn’t notice during the production process. We were able to quickly correct the problem and avoid any future problems.
Following the UCD process has allowed me to solve even the most complex problems by breaking each project down into a problem statement, then validating my work at every step.