Case Study

A UI for a new feature

Summary

The Opportunity

A client has an existing hardware-software suite that they sell to a specialized group of end users, and they need to extend its functionality. They don’t have UX researchers or designers on staff, so they required outside assistance in ideating solutions that their customers would find useful and would fit within their technical constraints.

A Solution

I proposed a series of three screens that progressively reveal more details about a collection of scientific experiments. I also created a drop-down menu of options that would provide the end users with the ability to share the results and take action on them.

About the Client

Brighton Science is a company that develops specialized instruments that help manufacturers measure an object’s “surface readiness” for bonding, adhesion, and/or coating.

For example, an aviation manufacturer may need to ensure that a wing surface is correctly prepared for painting to ensure that the paint they apply will not peel or crack.

Brighton Science’s signature product is the Surface Analyst, a hand-held, contact-angle measurement device used to perform quality checks in manufacturing.

The company also markets a software-as-a-service (SaaS) platform, known as BConnect, that combines physical sensors, system analysis, and an ability to share data with others.

This UX Design project was focused on creating a user interface (UI) for a new BConnect feature.

This feature will combine data from a series of special scientific experiments — known as GR&R* — that demonstrates the accuracy of the measurement device. Part of this new feature includes generation of a single report documenting the results.

* GR&R is an abbreviation for Gage Repeatability and Reproducibility, a standard technique commonly used as part of the Six Sigma methodology.

Design Opportunity

BConnect can perform individual GR&R experiments, but it is currently unable to combine the results of those experiments into a single, “multi-results view.”

Brighton has a lot of talented employees specializing in business, science, and engineering — including Agile software engineers — but they do not have any designers on staff.

They sought outside help designing a UI that will allow their customers — the end users of BConnect — to easily view and act on GR&R results. Currently, they are required to import and analyze the data in a third-party tool, such as Microsoft Excel.

They want the final interface to offer a multi-results view that will allow the users to:

  • visualize the data,

  • provide visual indicators for pass/fail status, and

  • allow for additional tasks and follow-up actions based on the results

The software engineers at Brighton also shared a user story, a common tool in Agile programming that helps to guide them in their customer-centric work:

As a BConnect user, I want to see the results of all GR&R experiments in one view. I want to go to my GR&R Project page and be able to easily see all of the data for the project. In order to avoid manual data entry into an Excel spreadsheet, I want to be able to see all of my data reported in a standardized format that tells me whether or not my gage (device) is fulfilling the requirements of the GR&R standards.

My role & collaborations

I collaborated with different team members on this project, and I also did a significant amount of work independently. The following describes the activities that required collaboration.

Stakeholder Interview

Prior to the stakeholder interview, I read the brief created by the pre-sales team, and I used it to generate some potential questions for the stakeholder interview. I shared these with the senior UX researcher who would be leading the interview.

During the interview session, I played the role of observer and notetaker. I observed and took notes on paper and with an AI-based note-taking system (Otter).

Rapid Prototyping Session

A team of UX designers, including me, quickly generated several ideas that we hoped would address the client’s request. When we were done, we had sketched a large number of concepts for consideration.

Tech Scoping Session

I received feedback on my sketches during tech-scoping session with a team of Agile software developers at Brighton Science.

This feedback included their judgements about the amount of programming effort that would be required for each, and whether the individual ideas were feasible from their perspective.

This session was led by by a senior UX designer. I played the role of observer and notetaker, but I was also available to answer questions about my ideas.

Kano Model Survey & Analysis

After the senior designer eliminated sketches that were deemed to be out-of-scope, the senior researcher sent out a Kano Model survey to the developers, seeking more refined feedback.

When the results came back, I worked with a small team of UX researchers to perform a Kano analysis, i.e, we categorized each idea to determine which ones would be most useful for me to work on going forward.

Journey mapping

Before I could design an improved system, I needed to understand the current system. The BConnect System, as well as Gage R&R, are both specialized topics that I was unfamiliar with prior to this project.

In addition to studying the notes from the stakeholder interview, I also started working on developing a journey map.

My process began with creating a rough flow chart of a possible series of GR&R activities and events, using the BConnect system from beginning to end.

I iterated on this diagram a few times, consulting my notes and a member of the pre-sales team in between iterations, until I was confident that it was accurate.

I then crafted a couple of journey maps that were more like those used in the UX discipline.

One represented the current process with the pain points highlighted.

The second journey map represented the proposed solution. It included the text of the user story created by the development team at Brighton, which would also be a foundation of my subsequent design work. This map had only three steps, instead of four.

Before

During

After

My initial concept designs

I focused on various screen- and interaction-ideas, including a page that showed visualization of GR&R experiment results, a button and pull-down menu for sharing the results with others, and an automated email message that would be sent to a quality manager when results were ready for viewing.

Although I often sketch on paper, during this project, I experimented with sketching my ideas with a digital tool (Figma) using components designed for this purpose (Lo-fi Wireframing Kit).

In addition to my effort, other UX designers were invited to participate in a rapid prototyping session. In the end, we generated a large number of concepts.

As noted in a section above, these ideas were shared with the development team during a tech-scoping session. I then collaborated with other UXers in performing a Kano analysis.

This helped me to determine which sketches would be most useful to flesh out going forward.

My final proposal

After refining my ideas based on the feedback from different sources — including developers and other UXers — I created a final set of UI designs that were technically feasible and met the client’s goals.

They also met a pre-defined “budget” of effort, a constraint that ensured that the developers could fit the work into their complex schedule of other projects.

My designs included a series of three “multi-report” screens that progressively reveal more details about a collection of GR&R experiments, if the user desires them.

I also created a Share button with a drop-down menu of options, including one that would allow the user to save the report as a PDF file.

The full proposal, including annotated wireframes and additional detail, was provided to the client as a PDF slide deck.

Challenges

1. This project involved a highly-technical topic requiring specialized knowledge that I didn’t possess at the beginning of this project, and which remained limited upon completion.

  • Two specific domains of knowledge related to this project: the GR&R technique and the Six Sigma methodology.

2. I was unable to test any of my concepts or final designs with actual end users. I had to rely on the developers’ perceptions of the customer needs.

  • This prevented me from uncovering any potential problems to my proposed designs.

  • Likewise, my confidence in the usability & usefulness of my designs was limited.

Want to see more case studies?

Click or tap here.