{"id":17167,"date":"2019-02-21T12:42:34","date_gmt":"2019-02-21T12:42:34","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=17167"},"modified":"2024-01-17T22:32:49","modified_gmt":"2024-01-17T22:32:49","slug":"build-better-products-conducting-better-user-research","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/build-better-products-conducting-better-user-research\/","title":{"rendered":"Build Better Products by Conducting Better User\u00a0Research"},"content":{"rendered":"

It doesn\u2019t matter how good you<\/em> think your product is if your users don\u2019t like it or find it useful.<\/p>\n

Ignoring the needs and desires of your users is like ignoring your product. The better you know your users, their environment, their needs, and the value they derive from your product, the better you can craft rewarding, satisfying, and engaging experiences for those users.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

This is what user research<\/a> is all about \u2014 understanding our users\u2019 goals, the actions they need to take to achieve those goals, and how your product can help them do so.<\/p>\n

Despite its importance, true user research remains a rarity at many companies. Customer support personnel and account managers are often tasked with gathering user feedback, which isn\u2019t necessarily the most effective way to guide product development.<\/p>\n

Let\u2019s take a look at how to conduct better user research<\/a> so we can build better products.<\/p>\n

User Research Roadblocks: Cost, Mindset, and\u00a0ROI<\/h2>\n

One of the most common mistakes made by executive teams is assuming that market research is the same as user research. Although there is some overlap between the two, user research is distinctly different from market research in both form and purpose.<\/p>\n

The two most common objections to conducting user research are cost and feasibility. Inviting customers on-site to conduct thorough user research can be time- and resource-intensive, and asking product leads or researchers to actually do the work can be disruptive and interrupt already time-sensitive projects.<\/p>\n

\"The mindset that market research equals user research can be especially difficult to overcome. Market research is best suited for capturing data about prospective users, not existing users, and tends toward opinions and trends rather than the actual behaviors of real users.\"<\/span><\/p>\n

If you want to cultivate a customer-focused mindset<\/a> on your team, it\u2019s crucial that everybody on that team is on the same page about why the product is being built in the way it is. Developers who lack insight into users\u2019 needs can\u2019t possibly hope to develop product features with any real empathy for understanding product decisions. This lack of understanding, in turn, often drives up costs and wastes time and resources.<\/p>\n

User research rarely offers instant results, which is why it\u2019s so difficult to secure executive buy-in. One way to mitigate this is to focus on what conducting user research will accomplish in tangible ways that executive teams will understand, i.e., reducing errors, lowering maintenance costs, or maximizing employee productivity.<\/p>\n

Real Examples of Solid User\u00a0Research<\/h2>\n

Before you can effectively pitch management on the benefits of user research, it pays to see examples of it in action and the kind of impact it can have on product development.<\/p>\n

Buffer: Validating Feasibility<\/h2>\n

Whether you\u2019re aiming for a minimum viable product (MVP) or gearing up for your product\u2019s beta release, it\u2019s crucial to get your hands on actual user research data as early as possible. Why? Because the earlier you can identify flaws or design possibilities based on what users actually want, the more time and resources you can allocate to developing features you know will resonate with your users.<\/p>\n

Think of it another way: it\u2019s much easier to steer clear of an iceberg than it is to stop a ship from sinking.<\/p>\n

<\/div>
<\/svg><\/div>

\"It\u2019s much easier to steer clear of an iceberg than it is to stop a ship from sinking.\"<\/p><\/span><\/blockquote>\n

Many startups opt to develop an MVP before ramping up production. Dropbox, Groupon, Twitter, and Zappos are all examples of companies that tested the waters with an MVP before committing to producing a fully fledged application. Although the degrees of user research conducted by these companies varied, one thing they all did was validate the feasibility of an idea before committing resources to developing those ideas.<\/p>\n

Social media management platform Buffer did precisely that before its launch. To test the commercial feasibility of its product, Buffer created two minimal landing pages: one with two steps and another with three steps.<\/p>\n

The two-step landing page allowed users to sign up for the service before it launched by entering their email address:<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

The second landing page was designed to test whether users would be willing to pay for the service. To do this, the second landing page included an additional step that included some provisional pricing information that users had to complete in order to register:<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

Users who went through the additional step proved that Buffer\u2019s pricing hypothesis was valid and worthy of additional tests. It might not have been the most rigorous test, but that\u2019s not the point. Remember \u2014 you don\u2019t have to reinvent the wheel if you just want to test a simple idea.<\/p>\n

Uber: The Value of Field Testing User Constraints<\/h2>\n

Ride-share app Uber has mastered the art of user research to discover real challenges faced by drivers in the field that would be almost impossible to account for in a production or testing environment.<\/p>\n

During one such field test, Uber\u2019s researchers discovered that, for busy drivers, navigating to the contact information of their next ride was cumbersome. The information itself was easily found but navigating to and accessing it while on the road was difficult, forcing drivers to pull over to plan their next ride.<\/p>\n

One driver in particular had set his device to save the number of his next ride in its own Contact card called \u201cMuppet.\u201d When the driver needed to contact his next ride, he used his phone\u2019s voice commands to \u201cCall Muppet\u201d instead of manually navigating to the rider\u2019s contact details.<\/p>\n

This insight was crucial to Uber\u2019s product team. The field research<\/a> revealed a user constraint that would have been very difficult to identify in a lab environment. This use case also highlighted the dangers of making assumptions about how our users interact with our products; there was nothing \u201cwrong\u201d with the navigational flow of Uber\u2019s app per se, but the product team simply had no idea that hands-free contact navigation was something drivers wanted very badly to improve their efficiency.<\/p>\n

Choosing the Right User Research Methods for Your\u00a0Project<\/h2>\n

So, now that you and your team are suitably excited by the incredible possibilities offered by comprehensive user research, how do you go about actually gathering it?<\/p>\n

There are several ways to collect and act upon user research data:<\/p>\n