Case studies
David IsmailovSr. User Experience Expert

The Value of Simple UX Research


‘Research’, when stakeholders hear the word they often respond: “it’s difficult”, “it’s a long process”, “we can’t invest time for it”, and my favorite one: “We know it all, we don’t need to do any research”. From my experience, this usually happens out of lack of knowledge regarding UX research process and the false perception that it’s a one time task. UX research is an ongoing process that never ends.

By using simple and effortless research methods one could redefine the entire user experience of a product. Let’s review a case study that demonstrates some of these methods and processes.

The project was to redesign an existing security software product named ‘WebInspect’. WebInspect is a product that analyzes and identifies security threats in websites/apps and suggests different remediations. The goal was to totally redefine the user experience of the product, from the ground up, and provide a new concept to the team.

My first impression of WebInspect was a bit overwhelming, a mature and complex software, tones of functionality and years that the UX didn’t get attention.


So where do I start from?

I take Alexandra Stoddard’s advise: “Slow down. Calm down. Don’t worry. Don’t hurry. Trust the process.

The first step was to to collect data, as much as possible. Data about the market, target audience, users and their roles, common/main tasks, breaking down the software’s information architecture and etc. At this point I start to make some assumptions based on information I’ve had gathered so far. For example, I made an assumption that QA team should be added as a target audience in addition to Security Manager and Security Tester/Expert. This, of course, will have to be validated later.

Next, I started to work with the software. The goal was to cover the main task/flows of the software: scanning websites for vulnerabilities, auditing the findings and figuring out how to communicate the findings and more, closely working with security experts and observing them using the software.

After gathering some initial information, I have had a better understanding of the software and the data. I could engage and lead more technical conversations and ask better questions. I’ve met with Dev, Support and QA teams, continuing to gather as much information as possible. One of the methods we used to prioritise and consolidate the features is X/Y chart. On X we mapped Complexity of the feature from User’s perspective and on Y axis we mapped frequency, how often the feature is used. Once the data got qualified, I could create more prototypes.

Image of X/Y chart on whiteboard
X/Y Chart

Most important part is meeting with actual users for interviews and, is possible, observe them using our software.

About prototypes, through-out the information gathering process I create prototypes, they help to validate the assumptions(problems/solutions) at earliest stage. Think about the prototype as MVP/Product on Lean Circle. In addition, these prototypes served as a key reference point for building constructive conversations, by highlighting the data and providing the logic to support the arguments. Nevertheless, I’ve found that its better to use them toward the end of the meetings, so the stakeholders won’t be distracted by the solution.

Interviewing the users and, if possible, observing while they use the software is the most important part of any UX research. We’ve conducted several customer interviews at their offices, over the phone and few more at HPE’s security convention event.

Prior to the interview, it is important to define the goals of the research. Based on the goals, we create a firm list of research questions. It sounds logical, but many people don’t do it and as a result generating questions on the fly at the interview. Having a list of questions helps us to stay focused of what we’re trying to learn and helps us avoid the leading questions.

WebInspect had 3 main sections:

  1. Scan interaction – The scan information and the tools to interact with it.
  2. Scheduler – Each scan can be scheduled to run on specific date/time.
  3. Report viewer/generator – Generate the report and view it within WebInspect and interact with it.

We’ve found that a big part of the users were QA testers, a persona that didn’t exist before.

So what I wanted to learn is: How users interact with the scan and its results, do they need to schedule the scan(and why?) and how do they report/communicate the findings?

(Check out our customer interview template in Research & Usability section)

One of the outputs we observed is that users completely ignore the so called “home screen” that provided news notifications and updates and went straight to the scans. So our action to this finding was to change the main screen to the “Scans” screen, moving the news/updates to notifications menu on the tool bar.

Another finding was that users usually communicate the findings by creating a PDF of the report and sending it to the Dev Team. So instead of having a full-blown report section in the software(it also costs a lot of Development time to maintain it from one release to another), in the new design, I suggested that we remove the report section, instead simply generating PDF report based on predefined templates and proving the ability to “auto-email to recipients” once scan is finished.

Our most important finding was that a big part of the users were QA testers, a persona that didn’t exist before. A persona that is very different to the previously defined by the way they report, their ability to understand the technical aspects of the security problems, and their systematic way to do tests.

Here are few prototypes that demonstrate how designs have changed during the process. (Visit WebInspect gallery to see final designs)

Initial Prototype - Home Screen and Main Navigation
Initial Prototype – Home Screen and Main Navigation


Prototype Version 2 - Home Screen and Main Navigation
Prototype Version 2 – Home Screen and Main Navigation


Prototype Final Version - Home Screen and Main Navigation
Prototype Final Version – Home Screen and Main Navigation


Research doesn’t have to be complicated or take a lot of time. As long as it’s done right and you know exactly what you want to learn, validate or discover, it is a straight forward process. And remember, research never ends, it’s an ongoing process that every stakeholder must take part in.


Liked the article? share with your fellow!

Got questions? drop me an email at [email protected]

Follow me on twitter, I share interesting stuff @dima_david