We start our projects with a foundation of insightful and effective user research to help establish a baseline for the perceived value of an existing experience and to understand anything that is not working effectively in the system. This is particularly important when we’re redesigning complicated, transactional applications. Up front user research allows us to identify and prioritize the key things we need to focus on as we move forward with redesigning a system.
Getting a clear understanding of what works and what doesn’t, is a primary objective we establish when a client hires us to redesign their application.
Unfortunately, there is also often some amount anxiety about conducting user research at this stage, especially when the application we are evaluating has been in use for a long time. Some business analysts and developers who have spent a good chunk of time evolving and maintaining these types of application often assume that usability research will be a waste of time and money, because:
- The application is out-of-date, there is nothing to retain
- The requirements gathering stage of the process has already been completed. There is no time or budget to address anything new
- We completed a survey and some informal interviews and got some feedback already
- There is a requirement to launch as fast as possible so there is no time to talk to anyone now
Taking some time to gain a deeper understanding of how your users are using your system at the beginning of the project saves time and budget in the long run.
Want more of our Point of View?
Sign up, and you’ll be the first to know when we’ve published a new article or podcast.
Consider Existing Users
We often work with clients to update systems that haven’t been refreshed in over a decade. Frequently clients plan to ‘start from scratch’ with the new system and don’t want to take time to study the existing system.
When applications like this are used regularly by people, sometimes to support their daily work. Radical change and migration to a new system can be very disorienting, no matter how bad your application is at the moment.
We use initial research to understand how users rely on the current system. We learn about:
- what they think works well,
- what doesn’t work as well as they’d like,
- and any workarounds they use when the system doesn’t meet their needs.
They will talk about the parts of the current process they like and all the nice to have features they would want. It is a fantastic opportunity to look for ways to improve or change a process, make it more efficient and ask questions about what parts of the process are really necessary. We often find that clients discover things about how their current system is being used that they didn’t know before conducting the research.
We’ve Already Completed Our Requirements
More often than not, business requirements are based on what the business needs to accomplish and any limitations of the technical environment. While these are important inputs for the project, business requirements don’t go far enough.
Business requirements rarely include input from the end user. Their goals and objectives may be different that you expect, and you won’t know exactly what they are until you observe them in the application. Early research can demonstrate that a process is not effective or uncover functionality that your competitor is providing that is gives their product an advantage.
There is often a concern that conducting initial research on an application will surface requirements that haven’t been documented and are out of scope for the project. Yes, people sometimes suggest things that are not technically possible or are out of scope. When this happens, it gives you the opportunity to re-evaluate the project priorities to ensure that the project will still meet the overall strategic objectives. Anything that the research surfaces that isn’t a priority for this project can be considered for future enhancements.
We’ve Already Talked to Our Users
It’s not uncommon for us to hear that the sales (or other internal) team has already talked to customers and told us what they want. When we hear that, it’s a red flag. Internal teams can struggle to get honest feedback from customers or ask the right questions to truly understand how well the product is working. It is natural to not want to draw attention to a problem. Internal teams can also become defensive if a customer insults their application, justifying decisions that were made instead of listening to the root cause of the complaint.
As outside consultants, we can facilitate the conversation as a neutral party. We find people will share their honest opinions with us and we can ask them direct questions about both their positive and negative experiences.
It’s All About the Launch
We often have clients come to us for help with a project that has a firm launch timeline and they feel that we don’t have time for any initial research. If the launch date is tight, we often recommend going live with limited functionality or minimum viable product (MVP) and conducting post-launch research on a limited feature set and some future concepts.
By building a lean version of the system and conduct some research on it so you can make updates before too many development phases have been completed. We use static concepts of future functionality to get some feedback on the application’s longer-term potential.
It is ideal to integrate user research during the requirements gathering stages of your project. Build it into the timeline and budget, so you can approach your project with an understanding the business goals, technical requirements, and user needs.
We are good at asking direct questions and uncovering how your customers perceive your product. We always discover things that surprise our clients, give them competitive advantage and help provide a valuable and engaging experience for their customers.
If you would like to learn more about our user research services. Please contact us we would love to chat.
By John Golden
John’s career in interactive media design began in 1995 and has spanned over two decades with a focus on developing simple, streamlined approaches for complex problems.View John's Bio