One of the key challenges I’ve been facing as a designer for a young startup is getting a good understanding of what is actually needed from the product when a new requirement comes in. People in general are bad at describing what they want, whether that’s in love or from products, and instead of telling you their needs they’ll tend to tell you how they want it fixed.
As a UX designer, my goal is to solve problems in as simple and delightful way as possible, but to do that I need to understand the why behind the what. Here are a few ways I’ve learned to help customers and product really define the problems we’re trying to solve.
Listen intently and ask a lot of questions
This is really the baseline, but when it comes to gathering real requirements, it is key to not only get what they’re telling you but also get what they’re glossing over because of the curse of knowledge.
Key things to look out for is when someone says things like “I’ll then pick some widgets”, words like “some” aren’t descriptive enough, and you’re going to have to ask how many some is.
Alongside clarifying the details is covering what someone glosses over, “I upload this file”, you’ll ask “where did that file come from?”
Why are you here?
It’s easy to think of technology as detached from work and life, especially if you’re the designer. But it is key for us to understand why someone is going to our app, and what they’re trying to get done there. To do that we need to make sure we understand why a user is wanting a new feature. Why are they on the application, the page, clicking on the feature? Diving into these questions helps us better understand how what we’re designing fits within the structure of their work and life.
Another aspect of this line of questioning is that it opens up the line of questioning around what comes before the feature; what is the user doing that makes them want to use the app and is there anything the app should do to better fill prior to the asked for feature.
How do you know that you’re done?
On the flip side of ‘why are you here?’ is ‘how do you know when you’re done?’, and with it we want to learn about the end of the process. What do you do after you finish with the feature, the, page, the application? And just as before, this should help us design things that have strong beginnings and endings… that fit well into the workflow of the user.
Requirement disagreement
Regardless of how good your team is, there will be times when you get requirements that you just disagree with. Dealing with these can be pretty difficult.
As before, the primary thing you want to do is first understand the reason behind the request; what is the problem that the user is dealing with. From there, talking over the requirements and seeing what you can do to alter them to something better.
Sometimes you can’t get the change you would like, and when faced with that it’s good to create two versions: the requirements one and the version that you think is a better answer. From there, evaluating the strengths and weaknesses of each, you’ll be able to guide an informed discussion as to the approach that should be taken.
Working as a UX designer is all about teamwork and knowing that the input from your customers and coworkers is invaluable. Requirements provide that input in a concrete form and we should put a lot of value in that, and dealing with a lack of information or weird requirements is on us. We need to take that input, make sure we understand it, and do our best to really work on solving the problem at hand. One of the worse things any designer can do is think that they’re the smartest person in the room. Be humble, be teachable, listen intently and create good designs for your users.