When designing a new product of any kind, you cannot overestimate the importance of knowing – and speaking to – your target users. Without them, you can be reduced to designing and producing something based on conjecture and hearsay, so you really shouldn’t be surprised when nobody wants to use it.
Despite this, talking to or actually involving your users in the design process can be very intimidating. You may have poured you heart, soul and money into something, only to have someone tear it down at first glance. Or worse, what if they love it? Now you have to commit to delivering your promises, probably to a deadline.
The answer is to get your users engaged early and keep them engaged with regular updates and chances for them to share their thoughts as production progresses. Here are some of the methods we use to get the actual users involved in developing their own software application.
Workshops are an excellent way to get early input from your users and make sure that you start off in the right direction. They work best when you do not to discuss your ideas or propose solutions but instead take the time to find out what problems people are experiencing so that you can target your design at solving the biggest issues first.
We usually focus on two major areas; the process as it currently stands and the people that are involved in it. Do some homework ahead of time and list the stages of the process that your product is hoping to slot in to. At the same time, work out who you think is involved at each stage. This will probably change the moment the experts, your potential users, get into the room, so be prepared.
Go through the process step by step and let everyone have a say in who needs to do what when, and where things go wrong. If you have a large group, it can be helpful to break them up into smaller teams and let them fill a wall or whiteboard with post-it notes.
Once you’ve got the process down, switch the focus to the users themselves. What do they hear, see, feel, and do in their role? What are their pain points? What would they like to gain in the future? Again, this is a good time to split into teams get everyone to spend some time thinking about what other people in the team go through. If the room feels like it might come to blows at any moment, you are probably doing it right!
If a real-world meet up is not feasible (looking at you, 2020), there are plenty of online tools that can help you get the same sort of information with online workshops and smaller team meetings. The principles remain the same, it just requires a bit more forward planning.
2. User interviews
Especially in these times of plague, large group sessions just might not be an option for you. In that case, one-to-one interviews can be extremely helpful.
The important thing to remember about any interview is that people generally want to make each other happy. In a large group this is mitigated a bit by anonymity but if someone is talking to you, and you alone, they will probably say what they think you want to hear. There are some fairly simple interview techniques that you can use to make sure that you aren’t getting the sugar-coated version of events.
- Don’t talk about your ideas! People know how much emotional investment there is in an enterprise project, they will tell you you’re great even if they hate it.
- Keep it casual. Formal, scripted interviews make people nervous, so they are likely to freeze and only give you one-word answers. Keep a list of conversation prompts, but don’t stick to a format.
- Talk as little as possible. In a user interview, the user should be talking. For that one hour only, your interviewee is the most interesting person in the world and everything that falls from their lips is absolute gold.
You should also get as many different user interviews as you can. As the interview lacks the large group element of a workshop, if you only get one, you are only designing for one person.
3. Prototype testing
Now you can talk ideas!
Once you have done a bit of design work, it’s great to get some of your workshop participants and/or interviewees back in to show them what you’ve done so far. Don’t be tempted to give a demonstration, it’s best to let them mess around with the designs themselves so that anything that is unclear or just plain broken comes up naturally.
You can test prototypes by printing each screen design off onto a separate sheet of paper and labelling where each button or link should lead. However, there are a number of software design tools available that will allow you to simulate the experience of using the app without writing a single line of code. This will allow the user to feel like they are really using the app and get you the best possible idea of how well the design meets their needs.
Since any simulation will be limited, it is best to produce a short list of the tasks that should be possible for your users to perform. This list should avoid giving any hints on how to use the app, you want to find out if your design is intuitive after all, so instead of saying “Click on the add button to add the item to your cart” you should instead just say “Add an item to your cart” and see how they get on.
As your users go through the task list, ask them to tell you what they are thinking. If they get stuck at any point, note down which task they were attempting and ask them to describe the problem. If multiple people get stuck at the same point of the process, it could be that you need to re-think your design!
4. Early beta releases
As soon as you have a functioning application you should be releasing it to users. If you have properly prioritised your development backlog and focused on the features you cannot live without, you could get to this point in the process surprisingly fast.
It probably isn’t worth setting up a full live environment or Appstore listing right away. Your first release will only be for your friendly users that have been with you throughout the process so you can afford to lower the performance and/or set them up as app testers. Of course, development should still be ongoing so any feedback you receive can be added to the list and prioritised along with the rest of the work.
The beta should be updated regularly with fixes and new features and you may soon feel confident enough to release to a wider audience. A public beta can provide a fantastic source of feedback in the late stages of the development process to help get to over the line into a full live release.
Involving your users in product design can be intimidating, frustrating, and incredibly rewarding; just like software design itself! If you would like to know more, get in touch to ask about our design services, or check out our other posts on app design and the development process.