Everybody has good ideas. You never know which ideas will lead to a great idea. Focusing everybody on users and their experience helps to keep ideas grounded and applicable.
Engineers and developers are inherently creative. They love to find solutions to problems. They love to build something which helps somebody to do something.
Once given a brief or specification, they’ll have lots of ideas about what the best way to solve the problem is, and be eager to start. Ideas will lead to new ideas, as the creator gets deeper into the solution.
The challenge can be figuring out which answers solve a real user’s problem and which are good answers looking for problem. Most developers at some point will have found a new language or framework and be eager to put it to use somehow. Most developers will have imagined a user doing something which they can make easier.
Unfortunately, it can be easy to start creating something without seeing if there’s a target market or user who really wants what’s being made. Luckily, it’s just as easy to check the ideas with real people and whether a user likes by doing usability studies.
Usability Studies
In Steve Krugg’s book Rocket Surgery Made Easy he says that any kind of user observation produces valuable information. People often think of usability studies containing specific methods like eye-tracking or heatmaps but simply watching somebody as they use something you made is often enough to get some insights.
Usability studies are also easy to do. You just get a user in front of your creation and ask them to use it.
I once designed a small interface which used arrows to navigate the interface. I thought it would be universally understood that the right arrow meant next screen. The very first observation with an end user showed that I was wrong. The user thought that the arrow pointed to another button and was a way of altering the value of the button. It only took a minute of seeing somebody else’s perspective to realise I’d assumed incorrectly.
Usability studies are also easy to do. You just get a user in front of your creation and ask them to use it. Steve Krugg offers more advice about what kinds of questions get the best responses, how to organise user observations and how to convince your company of the benefits.
Engineers in the User's Environment
One way of exposing developers to users is to have them help with the observations. There’s minimal training required to help and scripts remove any stress. Once a developer is talking to a user, all the ideas they have start to become grounded in somebody’s actual experience. Everything starts to relate to a real person and how the solution helps. It only takes a few observations before a developer starts to realise the difference between ideas based on real user problems and ideas based on imagined user experiences.
Recording Videos + Writing Reports
For developers who can’t be involved in observations themselves, videos help bring the insights to the developer. Videos also serve as an archive of previous observations and a useful reference to be able to refer to. Just remember that if a user is being recorded (audio or video) you’ll almost definitely need to get them to sign a form to give consent.
Summary reports of observations also offer a quick rundown of an observation and highlight key points found or things to investigate in future observations. They can also be useful for people involved in the observation as a way of reporting some of the things they saw which they found insightful.
But remember that when you write reports of observations make sure everyone tries to stick to stating things that were seen and avoid going into why something happened. Reporting assumptions is reporting a perspective and could hide the details of what happened. The details and facts might lead to different understandings from different people when read later. Different perspectives are useful.
Testing Ideas
Once you found a place to do observations or discovered a group willing (Krugg has tips on that too), they can also be a great place to test ideas out. This way developers can take their solutions and see what worked as they expected, and what didn’t. This kind of concrete, user-grounded feedback can help developers understand the users and produce software and products that better meets users’ needs.
One kind of observation is to just watch a user use a product or software (maybe even competitor’s product) to understand the context of the user experience. It’s useful to see why a user wants to use a product, and what expectations they bring to the experience.
Another kind of observation is to actively test ideas and assumptions. You can guide a user through a sequence of steps to see how they behave in certain situations or parts of a user experience. Trying to see if a user finds a certain menu option in software is a good example of this.
Both observations give value insights and feedback, even though they will be handled in slightly different ways. User tests need careful creation to avoid influencing the test and affecting the results. The best way around this is to start testing on people within your own business. Simply doing some tests will be enough to start getting an idea of what works and what doesn’t.
Advice
Here’s some things I’ve learned trying to arrange and carry-out observations and use them during product development.
- Try to use incentives of any kind, discounts, money, vouchers, even food (depending on the participants). People don’t like to give their time for free, and generally won’t. Speak to somebody in your company to see what you can afford.
- Start observations as early as possible. Use low-fi cardboard, paper prototypes, or sketches. There’s plenty of software that make prototyping easy, such as Adobe XD, or Invision App. For paper sketching or cardboard prototypes, Bill Buxton gives a lot of excellent suggestions in his book Sketching User Experiences.
- It’s really tempting (and a little difficult not) to draw conclusions from single observations. Some insights are safe to base changes on. However, it’s good to get a few observations done before making changes, so you’re sure that someone’s experience also occurs with other users.