This is my largest and most comprehensive UX work to date. I applied methods from f.Designs - Design Thinking, IDEOS - Human Centered Design, and the British Council's - Double Diamond to place the user first at this early stage startup.

Calibration Management.


May 2016 - Present

UX Designer

Product Designer


Design Thinking

Double Diamond


This is my largest and most comprehensive UX work to date. I applied methods from f.Designs - Design Thinking, IDEOS - Human Centered Design, and the British Council's - Double Diamond to place the user first at this early stage startup.

Starting a startup

A global market leader in the Calibrations & Measurement Industry approached me to lead the design efforts for a new startup. I was immediately intrigued by the opportunity to test myself in the startup world and see if I had what it took to deliver an end to end product.

1. Discovery

During the discovery phase, the goal was to gain insight and context about the problem we were trying to solve. Here are a few methods I applied.

A) Why that problem?


Simply put, it was the hypothesis of our Founder. His 10+ years of experience in the Calibrations & Measurement made him our resident expert. Along with this problem, he also shared his idea for a solution to this problem and even had a few hand-drawn sketches of possible interfaces.

These sketches and this solution had been what got him here in the first place. The international team, the high budget, the expectations, they were all influenced by his proposed problem and solution. So, I would take his raw ideas and start to chisel away until we could see what lied beneath.

B) Framing the problem

I wouldn't be very good at my job if I just agreed with everything that was presented to me. So I began questioning every aspect of the problem and solution. The goal here was to generate a list of elements, places, people, relatable experiences, and areas of interest to be explored.

A few of the questions that gave us some context were:


How many gauges exist in the world?

How do we measure success?

How are they managing gauges now?

How do they collaborate with other labs?

Who or what is our biggest competition?

What's our timeline?

What's our budget?



With a scope of work and areas of interest defined, it was time to roll up my sleeves and conduct some research. I would make the 60-mile trip every day for 3 weeks. Here is a look at the experience and data collected.

A) Immersion

For the first week, I was a fly on the wall. I simply observed. I shadowed three different employees for 2 days each. I tried to avoid disrupting their routines because then I could potentially corrupt my research, so I kept communication to a minimum during this time.


B) User Interviews

The interviews were all conducted in the respondent's place of work. It was kept informal since the technicians needed to continue working during these interviews. Here is a look into one of those interviews.


Meet Mike

I created a script and kept to it for the most part but I tried to allow the interview to be more of a conversation. More natural.


I let Mike know that my visits were to conduct market research. I reassured him this was not a performance review or anything similar. We shared a laugh and got into the interview.


How long have you worked with the company Mike?

I noticed you play guitar, I play as well, any other hobbies?

The white gloves are nice, what is there purpose?

The primary goal was to address a few problem statements I had formulated from all the current findings up until this point. I started broad and then got pretty specific. Here are a few of the questions that were asked:

Main body Questions

How do you know which Gauge to calibrate?

About how many gauges do you interact with each day?

Can you tell me how you locate each gauge in the lab?

Can you tell me how you locate the data for each gauge?

What data, if any, is a priority to you and why?

Can you recall a time you couldn’t locate a gauges data?

Tell me how you reacted to not finding this data?

How do you share this data with peers and other labs?

Can you recall the last time you had to collaborate with another lab on gauges?

Tell me how you felt about the collaboration experience?



I thanked Mike and let him know he was awesome and he had given me some great responses to review. He had a few questions for me and I was happy to answer. Since then, I’ve interviewed Mike several times and we’ve gotten to know each other pretty well.



With a good amount of raw data from the research conducted, it was time to start identifying patterns and working towards a concept.

A) Clusters

I formed two initial clusters. The first consisted of the “Gauge Service” and their behaviors, processes, and motivations. The second consisted of “Gauge Owners” and their behaviors, processes, and motivations.

These two clusters were accurate to the Founders initial problem and solution. Existing in the calibration world were two main audiences. One that needed a calibration performed, and one that would perform a calibration.

B) Insights

From these clusters, a few emerging insights came to be apparent. Here are a few of the statements:

Insight 1

Gauge data was fragmented across multiple storage methods. Accessing specific data at a specific time required a lot of time and effort.

Need a calibration record? Open the filing cabinet in calibration managers office. Need a manual? Go see the guys in manufacturing. Need to know the capabilities of the gauge? Look at the label on the gauge… no, the other label.

You get the point. This was a problem.

Insight 2

Collaboration between labs doesn’t allow much room for dynamic work. This is also true for collaboration among peers in the same lab.

I witnessed this process on several occasions and it was even mentioned a few times during interviews. In all, it would require about 6 different employees over 3 departments to complete a work order for a client.

Insight 3

Technology constraints were going to have to be considered at every step.

This was due to all labs inheriting the software and hardware requirements from the German HQ.

Windows 7. Internet Explorer 10. cringes a little



The research had been done. Key pain points were defined. The team had been briefed. It was finally time to create. We aimed to get from concept to MVP as quickly as possible.

A) Brainstorming

We knew the MVP needed to do 3 basic things.

Collaboration - A simple and quick means of collaboration between users. It would need to be as easy as sharing a URL.

Organization - A clear overview of all the gauges a user-owned and collaborated on.

Storage - A source of truth for all the data associated with a gauge during its lifetime.

B) Sketches

Considering the 3 items listed above, I started sketching some possible solutions. If you recall, the Founder had an initial idea for the possible interface so I considered this prior to creating my own designs.

I’d make as many logical judgments as possible, based on user interviews and observations, but I also let my creativity go wild at times. A mix of both is where I think the “money spot” is in Product Design.


Concepts of Gauge Profiles (Storage & Collaboration).


Concepts of the HomeScreen (Organization & Collaboration).

C) Team Brief

With dozens of different sketches done I presented a handful to the team for review. I expressed what my “top” pick was and how this would solve our problem. We then decided on taking this into a prototype. That prototype would then be tested among the subsidiaries.


5.Build, Measure, Learn, Repeat

This phased moved fast. The goal was to not get to lost in details and deliver a solution we could test and measure on real users as quickly as possible.


In an effort to save time, I’ll simply say that… we got it wrong. If you noticed in the above screens, that app is named “Calibration24”. After a months worth of feedback and meetings with different companies and employees, we were able to see that we had missed something. I documented as much as I could and from this, we would be able to better understand why we had missed.

B)The Pivot

Knowing what we did, our Founder decided to make a move only a Founder could make. We pivoted, hard. We had gotten some things wrong, yes, but we had also gotten a lot right.

I recall him calling us into a meeting and saying, “We are going to rebuild from the ground up. Let’s get started.”

One thing to note is that we researched, designed, and tested an MVP in the course of about 4 months. This was pretty fast considering our sized team.


For 2 weeks, we basically lived in a conference room at WeWork. It was a group effort this time around. We had enough data and insights collected that we could all contribute our own thoughts and ideas.

We came out with a new MVP, a new look on how management should be approached, and a new name for this app. Gaugebox LP.


6.Getting it right

Fundamentally, the app did not change much. We still aimed to provide an MVP built for collaboration, organization, and storage. We just needed to change our approach.

I won’t go into details about the UI/Branding here because I cover that in a separate case study. To me, UI & UX are two disciplines that require a careful application of methodologies and creativeness and I wouldn’t want to downplay one just for the sake of fitting it into one case study. Moving on…


A)Removing the bad

Based on the user feedback I’d collected from our prototype, I was able to pinpoint areas of confusion and frustration.

I identified one critical area of concern. The overlap of the two audiences in the founder's initial problem statement. The two different audiences were actually just one. With this insight, we would remove the need to select what type of user you were and built for one audience in mind.


A few other changes were made too, but these were more cosmetic and necessary for the new design system and brand.

B) Improving the good

We really did get a lot right, and I’m convinced that if we had continued with Calibration24 we would have had delivered a better product than 99% of whats available currently.

I stripped the interface down as much as I could. What we were building now was very similar to a cloud file sharing platform. This would mean that a lot of complex roles and states would be introduced into the interface. I wanted to keep it as easily consumable as possible. Leveraging whitespace where I could and being selective with color and type use. All in all, it felt much cleaner and leaner.



After about a month and a half of going 200mph, I had a beta prototype ready to be tested. The Founder and I headed back down to re-introduce the product to Lab Directors and WIKA management visiting from Germany.

For the most part, the Founder did the talking and I would answer any technical questions. Long story short, they were very pleased with the new product.

Then they asked, so when can we use it?

This was a big win for us. We achieved our first milestone. As nice as it was to hear that the management team was impressed, it was even better to hear it from the users. I went back to conducting user feedback sessions, this time at multiple locations, to ensure that the new product was the proper solution.

With this new momentum, we would move into refining the interface and really nailing down our creative direction.


Currently, is in V2 of beta. With V3 being our official exit. I’ve followed the same cycle as laid out above for every new feature or update.

This process is not a template, its dynamic for every problem/company, but this at least helps us here at Gaugebox ensure we are creating design solutions that are human-centered.


Thanks for reading, hope this can help some or at least offer a good perspective into what working at an early stage startup is like. Stay creating!