Risk Management Reporting: A UX Case Study

This is the process, or rather strategy, that I follow as a UX Designer

Mike Newbry
Aug 31, 2018 · 12 min read

About me: Since 2014 I’ve worked on a SaaS product called AirPortal that is a travel management suite. This article focuses on the process I’ve used to introduce a new feature into the software. You can find out more about my work at http://mikenewbry.com.

I’m often asked about the process of UX design, but I prefer to think of it as a strategy more than a process because it allows for a lot of per-project flexibility. I’ll be using a recent project to show how this strategy has worked for me.

Project Overview

Our team was tasked with taking an existing reporting tool and making it more robust. It had to include new functions such as search and filtering.

Background

In 2014 Christopherson Business Travel introduced Security Logic, a risk management tool inside our large SaaS suit called AirPortal. The idea is that you can have an at-a-glance view of where your company’s travelers are in proximity to potential threats, be it a terrorist attack, natural disaster or major airport delays.

Note: All traveler and company data shown herein has been anonymized.

This map shows all of a company’s travelers in the world along with all known disasters and potential threats.

When it was released the product received a lot of industry acclaim and many other large travel management companies scrambled to create similar products.

The main feature of Security Logic was the map, but there was also a feature that allowed the user to create and download reports based on the map information.

The existing reporting tool was a simple summary of the data produced by the map.

The Problem

This year our team was handed a feature request to make the report generator more robust and to add search and filter functions. At first this seemed like a simple request, but as with most things, as we began to dig into what was really needed we could see this would be a very complex product.

The Process

My UX strategy isn’t much different from most other UX designers. But where mine differs is that I tend think of it more as an ongoing, repeating cycle.

If a UX designer works for a web design firm, they can often finish a project and never think about it again. But in the software world your work has a much longer life cycle, so it’s important to think of it as an iterative process, not a one-and-done design.

When it comes to processes, teams often get caught up in the extremes. On the one side there’s process over product. In this extreme tickets are created, steps are checked off, cards are moved into different buckets — but the process becomes more important than the work.

In the other extreme the team plays fast and loose, jumping straight into prototyping and development without answering the core questions. The strategy I follow allows the project to remain agile while still making sure all areas are covered.

Another reason I view this as a strategy more than a process is that a process indicates a step-by-step routine that has to be adhered to in chronological order. In my experience it’s more important that each step gets checked off, but the order it’s done in isn’t necessarily as important.

Each of these areas has multiple steps that I’ve outlined in a checklist at the end of this article. For me it’s helpful to outline my Jira tickets for the upcoming project by using the checklist and notating which of the five major areas each ticket is a part of so it can be prioritized and story pointed.


Area 1: Listen

The first step in the listening process is to identify the problem. This is part of my Gap Analysis, in which you identify where you are now, where you want to go, and what it might take to get there.

In this case the mandate was simple; build a better reporting tool. But with any project it’s important to dig a little deeper and really understand the problem that you’re solving. Building a better reporting tool isn’t the problem, the problem is that the existing tool isn’t good enough.

Can the existing tool be adapted or improved? This is usually the most cost effective, but in this case it made more sense to start from scratch because the existing framework didn’t support all the functions we needed.

In researching the existing tool I found that users complained of it being slow. The new version would be connecting to the same endpoints and bringing in the same data, so I was very concerned that we could end up building something even slower than before because we would be adding layers of complexity on top of an already struggling infrastructure.

In the listening process it’s important to make sure that you’re listening to the right people. Using Pendo, we identified 5 power users that we could reach out to. I interviewed them and got their input on the problems with the existing product and what they would hope to see in the new product.

Be ready for harsh criticism. In fact, go looking for it. People are often afraid to call your baby ugly to your face, so find users that are willing to tell it like it is.

At this point in the research process it’s important to get as much feedback as possible, and be open to suggested solutions, but be careful not to put yourself in a box. If you commit early to a solution that’s presented to you, you can find yourself stuck on rails with something that precludes a potentially better solution.

Along with interviewing the power users outside of the company, I identified 5 internal users to interview. I met with them and conducted contextual inquiry. This means I observed them using the existing product in their native work environment and allowed them to walk me through their workflow.

Finally, I conducted user observations using Fullstory, and watched how users were interacting with the current reporting tools. Fullstory is an amazing analytics tool that allows you to be a fly on the wall and watch users interact with your product in real time, without that bias that is introduced from the user knowing that they’re being watched.


Area 2: Outline

It’s meeting time! The first step in the “Outline” area is to assemble your key stakeholders and get their buyoff on your vision of the project. This is my time to present the findings of my UX Research and make my recommendations based on the data I’ve collected.

No one likes more meetings, so I always keep them short and on point. The purpose of the meeting is to make sure everyone is on the same page and ready to move forward with the project. The goal of the meeting to identify your Minimum Viable Product, and to begin writing the business requirements and deliverables. It’s also a good time to start thinking about and discussing your Key Performance Indicators. In other words, what does success look like and how will we measure it?

Even though my company is small, we still strive to follow the Agile method and work in highly collaborative cross-functional teams. I already had a pretty good idea who would be on this project team (it’s not that big of a company, after all). I was already assigned to lead UX and UI design. Jen would be the project manager but also act as the product manager. We didn’t have a dedicated scrum master, but that is essentially the roll she would be filling. Jeremiah would be the front-end developer. Nick would be the back-end developer, and Jasmine would provide our data analysis. From this point on we would be having regular project stand-ups with this team.

“Hey, why do you get to be in the middle?” Because this is my story, that’s why!

While outlining the project, we performed a SWOT analysis on the product (Strengths, Weaknesses, Opportunities, Threats). In discussing the strengths of what I was designing it occurred to me that this had the potential of being a more global tool. If it was done right, it could become a global reporting tool which would eventually become a main feature of AirPortal.

So knowing that this product could become a global reporting tool, why wouldn’t we change the scope of the project and build that from the beginning? Scope creep is something we try hard to avoid, but in this case it seemed to make sense. But after discussing it with out back-end architect, it was determined that our database wasn’t ready to handle global queries. That’s why it’s important to include all your developers early in the design process. We could easily have gone down a long road only to have to backtrack.

One of my primary concerns with this project would be performance. I voiced these concerns with the developers and Nick said that he would do what he can on the web services side to speed up the queries. Jeremiah suggested that building the front-end in React, something we hadn’t started using until recently, could also improve the performance.


Area 3: Wireframe

In this entire UX design strategy there tends to be a lot of overlap between the areas of focus. This is particularly true in the areas of outlining and wireframing. In the case of this project we had spent so much time outlining that we were able to spend less time wireframing.

Mapping the user flow is critical

Not every project will need low-fidelity mockups, and not every project will need high-fidelity mockups. But it’s hard to imagine a project that doesn’t require a map of the user flow. Getting this right will save you hours — no, days, maybe even weeks of extra work down the road.

There’s software dedicated to mapping user flow, but sometimes a few hours with a whiteboard is all you really need.

The wireframing process is where you’ll really apply the principles of Atomic Design. It’s where you start to really deconstruct the product and identify the core elements of your project so they can be arranged to fit the needs of your user flow.

The best way to test your user flow is with a low-fidelity mockup. It’s a good idea to use Balsamiq or something similar that will keep your hands tied and force you to focus on the function more than the form. From there you can conduct your first round of user testing to discover whether you have the user flow right or not. If you have a UI QA (which we didn’t at the time of this project), now is the time to involve them and get their feedback.


Area 4: Prototype

Prototyping is essentially creating a functional, high-fidelity mockup. The question is often asked, “what’s the best tool for prototyping?” My answer is it depends.

First, you should use whatever you’re most comfortable with and can get the job done in time. If that’s Sketch and Invision, great. If it’s Photoshop and Adobe XD, whatever. Having more coding experience than most designers means that I often prefer to prototype using HTML and CSS.

As long as other people can look at your mockup and navigate it as though it’s a finished product, that’s what’s important. The art is more important than the medium here. It’s hugely advantageous to have a solid design system in place that will allow you to pull existing elements together to create a user experience that’s consistent with your existing products.

QA and Test Engineers are often an underutilized resource. Rather than only involving them at the end of the sprint to test the code, use your mockups to involve them early. Hopefully your test engineers have been trained to spot design flaws as well as code bugs, but even they they haven’t they can often provide an analytical view of your user flow and provide valuable feedback.

A rookie mistake in UX design is thinking that the purpose of a pixel-perfect mockup is to be able to hand the project off to development and never look back, unless it’s to be able to go back to the devs and say, “HEY! You didn’t follow my mockup!!!”

There’s two major problems with this thinking. First, the handoff to dev should be a soft handoff whenever possible. Meaning that you’re not just throwing it over the wall and saying, “call me when it’s finished.” More on that in the next area.

The second problem with this line of thought is that you’re missing one of the great opportunities that comes with having a functional mockup: User Testing. In the case of this project, Jen and I conducted extensive user tests using the mockups that I had created in Sketch and Invision.

Screenshot of one of many screens I created in Sketch and loaded into Invision

I had Jen lead the user tests because I was afraid that as the creator of the mockups I would inadvertently lead the user and bias our test results. I observed as she gave the users scenarios and tasks to complete using only what was in front of them.

Creating a UI is like telling a joke. If it has to be explained it probably isn’t that good.

If the user asks for additional instructions besides what’s right in front of them, you know that your UI isn’t intuitive and you probably need to improve it.

The scientific method states that a hypothesis has to be falsifiable. You should take a similar approach with your user testing. Welcome opportunities to be proven wrong, then go back and iterate as many times as necessary until your hypothesis, or rather your design, is proven correct.


Area 5: Execute

You’ve done all the design work. You’ve tested it. You’re ready to hand off. Done. Right? Not if you’re lucky enough to work on a highly collaborative team.

My handoff to the dev team is very transitional. In some cases I’m able to assist in the front-end development. In this project I was able to write a lot of the CSS and work on some of the React components to help keep the project moving. You might not always have this luxury, for example some teams work with offshore developers and communication is limited. But wherever possible you should work as a cross-functional team.

It’s important to have regular project stand ups with your team even during development. Keep a close eye on how the development is progressing, so that you can catch derailments early. Be available to answer questions about the design and be ready to approve suggested changes when you can.

It’s finally in Beta! But the work isn’t over yet.

Even the launch of the product should be transitional. In the case of this product we chose to have an Alpha and Beta Release. This will allow us to collect data from select users. We will use analytics tools like Fullstory, Pendo, Domo and Qualtrics to track adoption and get user feedback.


Back to Area 1: Listen

As I stated earlier, software has long life cycles. Don’t expect your product to be perfect in the first release. It’s better to launch early, iterate often and be ready to fail fast. This lets you gather data from real users, and helps you avoid sacrificing the good for the perfect.

After a product is launched you should schedule time to conduct more contextual inquiry and see how users are applying the product in their native workflow. Conduct regular audits of the product and make sure that your QA is including your product in regression testing to ensure that it doesn’t break down the road.

Bug fixes are always highest priority, but beyond that look for product improvements and feature requests and then start the UX design cycle again. Look for opportunities to scale the product or, if necessary cut out parts of the product as they become obsolete. Always be willing to let go of old work.

Summary

Our new product was shown at the annual Global Business Travelers Association trade show and it received a lot of positive feedback, with some potential clients saying they’ve been looking for something like this and we’re the first company they’ve seen that offers it. That’s a win in my book!

Our team has been praised within the company for making our release deadlines and going beyond the original requirements. One of the best compliments I received was from my own project teammate, Jeremiah:

Thanks for being great to work with on the new SecurityLogic Reporting project. We were able to build that thing so fast because you were so easy to collaborate with and quick to come up with the solutions for design problems we ran up against. That was a fun project.

Below is a checklist that I’ve created to help ensure all areas of the strategy are being fulfilled. There are lots of UX design strategies. This is mine. It might not be perfect, but it has worked for me.

This checklist can be downloaded at http://mikenewbry.com/uxstrategy.pdf.

Mike Newbry

Written by

UX Designer | Web Developer | www.mikenewbry.com | www.linkedin.com/in/mike-newbry/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade