User Experience Research (UXR) for Engineers
User Experience Research (UXR) for Engineers
Why should you care what the user says and what to do about it
User Experience Research (UXR) is a systematic way of learning what end users of a product or system need and want. Often it is about understanding current behaviour, and at times pain points or workarounds to help the user achieve what they are trying to do. . It is also known as user research, sometimes specifically usability research.
Believing that user experience research is solely about the user interface is a huge misconception. An experience has to come together to match what the user is trying to do and what the user is able to do. If the code does not work how it is supposed to you will see it quickly at least in usability. Research is about making sure you understand and can observe those two things throughout the process.
What does day-to-day UXR look like in practice
If you have a UX Researcher in your organization they spend their time doing things like meeting stakeholders to understand the business context and upcoming needs. When they are not in internal meetings, they spend focused time planning or executing research. The execution of research is sometimes called being “in field”. Depending on the project needs that might mean remote interviewing or observing of users, shadowing them or seeing how they work, setting up some usability studies, analysing some data coming through, or looking for other sources of data and insights. They also could be wrapping up projects by preparing debriefs, material for their stakeholders to use or other internal processes like updating JIRA.
Source: XKCD
Why should engineers be interested in user experience research
A few examples are highlighted above but there are more solid reasons to understand your potential or existing users a bit better.
Impact to projects
By having a better context of what your users are trying to achieve then you will be able to think through the problem not only from the ideal technical solution but also being able to understand what users need.
Transferable skills
Being able to ask the right questions and interpret a users’ needs are highly transferable. For example, asking the right questions can unlock a lot of situations and clarify any misunderstandings. You can use those skills with your stakeholders, and team members, and even in a job interview situation.
As someone with a technical background, it is likely you will have good analytical skills. Putting them to use in a user situation is also helpful to strengthen your existing skill.
For example, if a team member is having difficulty getting a task done by employing a similar style of questions you can understand their challenges and how you might help them move forward.
Better user and business context
The more you have a chance to work with teams that are a customer or user-facing the more context you will have. It is always good to understand some things like where the business is heading, what customers are being targeted, and what are users are trying to achieve by using your product or service.
Users can use language that does not align with the internal software tag or labelling. An example from a previous project was that the end users referred to a task they were trying to achieve as reviewing their performance dashboard. However internally it was labelled by the engineering team as an “activity list”. It made it confusing to have two different names for the same thing, particularly for teams who were user-facing - there was constant label switching. Having one consistent, cohesive name made it easier for communication, documentation and alignment.
Measure Twice, Cut Once
This is a related point but the more context you have the less likely you will have to redo something. It will make the software development process go a bit smoother, and ultimately make you and your team look good. Rework is frustrating, especially when it’s avoidable. By spending a small amount of time upfront you could be saving many hours down the track.
More influence
With context, you may be able to speak the same language as your Product Manager or your Product Design partner. If you are up to speed at the same time the overhead of working with you becomes a lot easier.
Focus on User Research (behaviour) or usability (ease of use and usefulness)
Depending on where you are in the development cycle you could get involved in different research. Each phase has some overall objective questions, these are not what you ask your users.
Early Work Phase
There is no definition of the feature yet and it does not exist yet. This work tends to be exploratory in nature. It will focus on current behaviour and needs, capturing how users do things, workarounds and pain points. Might also include understanding who the target user or customer is.
Main questions that you are trying to answer:
What are these users trying to do? What are their pain points and workarounds?
Late Work Phase
The project is very much defined and some early or middle-stage designs/mockups/prototypes have been created. The focus on this part will be things like design validation, and usability.
Main questions that you are trying to answer:
Is it easy for our target users to do what they need to do? Does what they do align with what we had envisioned?
How to get involved
Your level of involvement will depend on who is in your organisation that you could partner with. Try these options in this order. The further down the list, the more hands-on you are likely to need to be.
Find the UX Researcher on your team or ask your Product Manager
If there are none, work with Sales
If there are none work with Customer Support
If there are none of the above teams - work with the CEO
Time commitment
UXR can be an activity that you do consistently or once-off. It depends on your goals and how much time you can invest. It should be noted that speaking to one or two customers is not research, it is a conversation. Conversations are fine but will give you a different outcome that may be biased toward the customers you spoke to.
Shadowing a team who are already doing a research project would be the easiest way to get started. They will also give you a sense of when and how you can participate.
Other useful articles or material to help you
When to Use Which User-Experience Research Methods
How to discover what users NEED and not what they WANT?
Why is it important to focus on user needs as opposed to requests? - User Experience Stack Exchange
User Research Basics | Usability.gov
A step-by-step guide to user research note taking | by Arnav Kumar | UX Planet
Consider trying out to participate in research. Start out by sitting in on a user session organised by one of the cross-functional partners. It can not only help you in your work but also sharpen a skill that is often neglected by software engineers.
If you are in a role where you want your engineer partner to be involved or introduce UX Research to them, send this article over to them. They may find it interesting.
Thank you for reading the article! You can help us:
Subscribe using this button
Share this directly with your peers and others who will find this helpful. Apply what you have learned and teach it to someone else, it will make it easier to recall later.
Share this article on your Social Media (Twitter (we’re @readaskwhy), LinkedIn)