Creating Solution-Centric Interfaces
What is an interface? Why does it exist? As developers, designers, or creators, we should assume that an interface is a means for a user to solve a problem through software. Focusing on the transformation of a problem into a software solution allows us to ensure that we are creating something that truly adds value to the end user. In this walkthrough, we will expand on the above principles with a proven design process using a sample problem statement:
A production manager’s job places them both in the middle of a factory, and at their desk to analyze production metrics. They shift between the two multiple times per day.
How do we start to break down this problem? We can break the problem down into a set of user needs. At this stage, we should work as quickly as possible to expand the problem into a list of thoughts on directions to take to solve the problem. It’s important that we don’t get invested in any one idea at this point. We can refine them later, but for now, go fast and explore the possibilities! If we start thinking about our sample problem statement, we can produce needs such as…
User needs a way to view production metrics on the go. User needs a way to access office computer remotely. User needs a way to make quicker trips to their office. User needs a way to identify production metrics from looking at a production line. User needs a way to be alerted to a struggling production line.
Once we’ve word-vomited our user’s needs, we can start to explore what filling those needs would actually look like. Even if a need looks particularly ridiculous, it’s fine to carry it through this stage since we won’t be focusing in on the details yet. A storyboard is a great way to start this exploration because it allows us to sketch out the problem, the interface interaction, and the resulting solution. Let the following sample serve that artistry need not apply:
Don’t put the Sharpie away just yet. Once we’ve expressed the user needs as storyboards, we have an opportunity to examine their feasibility. Start to think, how would an interface assist in solving the need? We’ll take our best guess and draw it out. No code, no photoshop, Sharpie on paper. This is where we’ll see our ideas start to sink or swim. A good interface will solve the problem without complexity, and not require any auxiliary functions. While still not focusing on details such as wording or icons, we can establish the feasibility of solving each individual user need with an interface.
So we have an interface, if only on paper. Is it a good interface? How do we know? Nielson’s 10 Usability Heuristics are commonly used to identify issues with an interface. Don’t let the 1995 date fool you, those classic concepts still make or break today’s interfaces. It is helpful to engage an unbiased partner for this step, to remove any ability for your personal bias to affect outcomes. For each violation of the heuristics, list a rating of the violation’s severity, so that changes can be prioritized. In the sample below, note how each change is specific and actionable:
User Testing. Almost a dirty word in some circles, but it’s undoubtedly helpful and surprisingly easy. You don’t even have to conduct the tests anymore, due to (paid) services like UserTesting.com. To do a user test, you’ll need a functional prototype, so now is a good time to spin that up. You can use a GUI solution such as InvisionApp or Axure or even slap something together in HTML (I chose this route, with Bootstrap+React). Once you have a prototype, it’s as simple as presenting the user with the prototype and the problem statement, and watching how the user attempts to solve the problem. If you’ve truly focused on a solution to the problem, the user should be able to solve the task. If not, it’s time to take a step back and revisit the Usability Heuristics, or perhaps start fresh from another storyboard.
Once we’ve come this far, we have a prototype that has been confirmed by users as a solution to their problem. There may have been some bumps in the road, some potential left untapped, but that’s where A/B testing comes to the rescue! We can simplify our problem statement down to one finite task within the interface that we need tested, implement the alternative design, and serve users both versions until it is clear which design is more effective at assisting the user. Take a look at the below example. Which version would you think was chosen?
Starting the design process with a problem statement, and steering the rest of the design towards solving that problem, is a simple yet effective thought pattern to ensure a top-notch user experience.
