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.
During the discovery phase the goal was to gain as much insight and context to 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?
What’s 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 everyday for 3 weeks. Here is a look into the experience and data collected.
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.
C) User Interviews
The interviews were all conducted in the respondents 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.
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.
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 cluster 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.
From these clusters a few emerging insights came to be apparent. Here is a few of the statements:
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 mangers 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.
Collaboration between labs doesn’t allow much room for dynamic work. This is also true for collaboration between 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.
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.
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.
Considering the 3 items listed above, I started sketching some possible solutions. If you recall, the Founder had an initial idea for possible interface so I considered this prior to creating my own designs.
I’d make as many logical judgements as possible, based on user interviews and observations, but I also let my creativity go wild at times. A mix of both is were I think the “money spot” is in Product Design.
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 down play 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 pin point areas of confusion and frustration.
I identified one critical area of concern. The overlap of the two audiences in the founders 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.
Except our founder has a different approach to engineering products, he is a perfectionist. A characteristic that is synonymous with German Engineering.
C) Less is more
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 alot 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 Gaugebox.com 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!