User research is learning what your customers are doing and why they are doing it. If you understand behavior and the feelings attached, you can improve the customer journey and create an exemplary user experience.

For example, today, when I pulled into my garage, my house knew I was home. More specifically, the thermostat knew I was home and adjusted the temperature accordingly. Nest knows that for its users having the thermostat adjust when they are home or away not only saves them money and saves energy for the rest of the world but that doing so automatically gives the user an experience.

On my way home, my car turned on my commute route when I reached a certain point on my drive. And, some days when this happens, my car also points out faster routes or advises me of slowdowns or accidents. The manufacturer understands that commuting can be stressful and giving information and alternate routes and advising of timelines and such improves user experience.

Customer Experience is Your Brand Differentiator

Giving your users an exemplary experience can increase sales, develop customer loyalty, and generate brand advocacy. In fact, it has been said that customer experience is now more of a brand differentiator than price or product. And, that 86% of buyers will pay MORE for a better customer experience.

Bottom line, doing user research to ensure an exemplary customer experience is critical to delivering a superior product.

Yet, according to a McKinsey & Co. report, “The Business Value of Design” over 40% of companies surveyed aren’t talking to their end users during development.

User research before and during custom software development is an important piece of ensuring that what you develop is not just useful to the user but also easy for them to use. It also highlights the features the users prioritize not what you think they want.

Recently, our team worked with three different organizations on user research projects prior to and immediately following strategy sessions. There were three different results that impacted the scope and the extent of the projects.

Feature and Scope Reinforcement from Observations with End Users

After completing a two-day strategy workshop, one client with a national presence and warehouses around the country wanted to make sure nothing was missed. Additionally, they wanted to validate the assumptions they had made during strategy sessions, were there any discrepancies? Had they missed something?

Our Director of Product Design and a Senior Product Navigator went out into the field to shadow sales reps. To ensure they had more diverse insights, two locations in different states and two salespeople at opposite ends of the age spectrum were shadowed.

As this app was going to completely replace what was in use, there were several critical factors that needed to be reinforced prior to beginning development:

  • Understanding the importance of each step in the reps process in order to verify features scoped in discovery was as critical as initially thought
  • End user sentiment around the project - do they love the idea of a new app or hate it with users across all age groups, understanding the amount of change the end user would tolerate was important for user adoption
  • Sanity check - after doing discovery and walking through processes was everything captured accurately or had something been left out or was there a feature that was not as important and could be removed

From two days of shadowing, a few observations came to light. Sales reps would be at times using the app in a Walmart parking lot where it was 107 degrees, thus taking into consideration the potential of a phone to overheat. This meant thinking through the physical aspects of the job and how it might impact usage was reviewed.

It was also realized that scanning was a make-or-break feature. When there are ten steps in the process and scanning is two steps but watching the process you realize that if scanning is slow it breaks down the whole process, then features around scanning need to be reinforced.

For this company, this observation led them to spend an extra two weeks in development ensuring that the scanning piece was correct. Even if it saved a second per scan, there was so much that revolved around scanning it would save the company exponentially more money than the cost of the additional development time.

Change management and user adoption can not be underestimated in custom software development. In the field, talking to end users, there was a sentiment that the app they had was fine. To have end users be more accepting, the app was designed in a straightforward fashion. For example, keeping elements in the same place on the screen because users have so much muscle memory of knowing where everything is in the current program. The changes were more about making the program faster saving time and making the process smoother for better efficiency.

Finally, the sanity check. Walking through a day to observe what other communication and steps outside of the application could potentially be optimized and brought into the app that weren’t considered. From watching the process, specific features were identified that were determined to be a higher priority and were worth spending more money on. At the same time, others were designated as not being as important and less money was put toward those.

The ROI of user research? Discoveries that saved the company money in excess of the cost of the user research and gave everyone involved the confidence that was was being built was what was needed.

Feature and Scope Changes Based on Focus Group Research

The adage build it and they will come definitively does not hold true in custom software development. If a user doesn’t find the product you build helpful the adoption you expect will not occur.

During a recent strategy session, a company’s stated objective was “100% of employees will utilize the app as their go-to resource for self-serve information.”

That statement led our team to suggest user research in the form of a focus group of end users. By gathering a group of end users, we could understand what value propositions would be most likely to drive high adoption of the app in order to achieve the company’s stated objective.

During the time with the focus group, three different user research methods were used to gather important insights into how they would use and interact with the potential app.

In the Dot Voting Exercise, a variety of information was given and participants were asked to place their “dot” on a scale of least important to most important based on how they valued the information.

The items the group voted as most valuable were then discussed in more detail. Takeaways from this exercise brought to light that what senior management at the company thought would be helpful wasn’t on the radar of the users in the field.

That being said, the end users were excited about certain aspects of the app. For instance, company-wide messages delivered in an app would give higher visibility and a place where communication is documented. This is something that was missing from the way they were currently delivering messages across the organization.

The second exercise, I Like, I Wish, I Wonder, gave the group the opportunity to weigh in on low-fidelity design concepts. Results - an awareness that participants liked the reporting function of the app but were unclear about certain pieces that related to their crews.

The final exercise was an essay where individuals were asked to write for fifteen minutes what an ideal app for them would look like. The themes that emerged from this exercise were job-sites, schedules, crew& materials, a company directory, and a resource Hub.

Overall, the focus group brought to light and reinforced the type of platform recommended. Initially, the company had thought a native mobile app would be the way to go. However, there were HR and continual update concerns that made a responsive web app a better fit. A mobile responsive web app is simply a website built to adapt and work beautifully on any device or screen size. It doesn’t require an app to be downloaded and installed, users simply visit the website URL, and the site adjust to their screen size.

And, it brought clarity to the features that end users wanted and would appreciate changing the scope and features of the project to better achieve the initial objectives set.

User Research That Determines Custom Software May Not Be Necessary

Occasionally, user research helps a company determine whether or not to even proceed with a custom software product.

Before moving into strategy sessions with a marketing production company, our team did user research with their top five clients. The company felt that clients had a painful process putting together sales proposals and hosting marketing content. Their concept was to build a client portal that would allow clients to host their information and put together proposals and would create ongoing monthly revenue for the client from hosting.

However, their clients when asked said, “please don’t do this, the process may be clunky but it is everything including a CRM for us.”

With the realization that the product the company wanted to build wasn’t wanted by their clients. We came back to them with 3 recommendations. The first was to add a service to their organization. Do the marketing for their clients and not just the materials. The second was to acquire a competitor that is doing everything and then enhance their process. The third was to build out a system and spend a million dollars or so for their clients but in reality, they didn’t want to build something their clients wouldn’t use.

The importance of User Research prior to and during custom software development can make or break a project as seen in the examples above. At the end of the day, the value of accurate insights from users themselves can be seen in additional revenue, process efficiencies, and time-saving.

We will leave you with one last example from the McKinsey article:

“One online gaming company discovered that a small increase in the usability of its home page was followed by a dramatic 25 percent increase in sales. Moreover, the company also discovered the improvements beyond these small tweaks had almost no additional impact on the user's value perceptions, so it avoided further effort that would have brought little additional reward.”

User research leads to a better client experience and higher adoption by users creating client loyalty and brand advocates.

Problem-Statement-Webinar-PDF-no-date

Start with: What problem are you trying to solve? 

One of the activities we work through revolves around refining your problem statement. A problem statement is the key business problem that needs to be solved. In software development, it states “what has to be done” for a project to succeed. It does not say, “how it has to be done.”

We use the 5W’s + 1 H format as well as the SMART Framework when establishing a problem statement. In fact, you can draft your own problem statement by using our free download. This download will get you thinking through some of the questions and answers prior to starting your project.

Download: Problem Statement
 
Ready to get started?