Low fidelity prototype testing to set product direction.

Low fidelity prototyping and user testing of a new product hypothesis.

I was excited to hear from Joe Malandrucolo. He was my engineering colleague at Tylr Mobile, where we worked on WorkinBox together. He is CTO at his new venture, looking for design help. Joe introduced me to his co-founder and CEO, Charlie Franklin. Compa is for talent teams who want to stop losing people over pay - it is a talent deal desk that lets companies create market data based on candidate insights. 

Compa was looking to add new capabilities to their platform. I designed an eight-week program to help them explore existing hypotheses, develop new ones and test them with potential customers. We ended the program with a “mid-fidelity prototype” of a clear direction which had been validated through several quick rounds of research. I had kept Compa’s front-end engineer/designer up-to-date throughout our project, so it was easy to do a warm hand-off. The work is under development, and I look forward to future projects with the team.

Because this work is not yet live, details of the product are obfuscated.


 

“We were pretty sure we knew what we wanted to build. Matt led a process that showed us we really wanted to build something different. He helped us move faster and feel confident we were building the right product from the start.”

— Charlie Franklin (CEO, Compa)

 

Low fidelity prototypes

Prototype testing on Zoom

Medium fidelity prototype


In my first conversation with Charlie I dug in to understand what type of project might be helpful to Compa. As an early stage company they had an initial product in customer hands and were getting positive feedback. With one designer on the team who had his hands full with near term design work - Charlie was looking for support to explore a new feature.

I followed up a few days later with a proposal I thought would work. I suggested we start with a design research phase to develop a detailed point of view of what problems the new feature could address. I wanted to know how recruiters work today, what tools they use and who is involved in recruiting decision making. This design research phase was to be followed by several design sprints to respond to what we learned and additional design research to test rough prototypes.

Charlie wanted to respect my process but I could tell something didn’t feel right to him. When I asked what was going on, it became clear that Charlie had a firm conviction about how this new feature would appear. I suggested we rearrange the phases so we could test his hypotheses as soon as possible. We started with creating testable prototypes and then testing those prototypes with current and potential customers. The design research interviews were divided into two steps. In the first part of the session, we would start with more open-ended need-finding, and during the second part, we would share our low-fidelity prototypes to test Charlie’s hypotheses.

These sessions were enlightening. We learned rather than considering the new feature as a stand-alone/bolt-on component; customers imagined the new feature distributed across the existing areas of the app – a layer across the entire product. During subsequent design sprints, we incorporated this learning and again tested this direction in research with potential customers.

After setting this direction and creating medium-fidelity prototypes, it made sense for Compa’s designer to take over. This project was a fun collaboration – I like how it illustrates the importance of being flexible with process. In many cases, it makes sense to start by testing firmly held convictions – as long as they are only loosely held.

Previous
Previous

WorkInbox

Next
Next

AT&T Design Thinking Toolkit