Heap: Event Repair
- ← Projects
- Date:2020
- Role:Product Designer, VP Design
Background
Heap provides behavioral analytics for websites and mobile apps, with a twist: instead of requiring customers to define the behaviors they want to track ahead of time, Heap collects all user interaction in a raw form ("autocapture") that supports retroactive definition.
I joined Heap as VP Design and sole designer when it was a Series B company of less than 100 people. Over two and a half years I built the design practice as the company grew from Series B to D.
That included hiring a team of six designers; creating a pragmatic, cross-functional product-development process in collaboration with my peers; providing strategic leadership as part of executive team; and serving as interim VP Product for much of 2019.
Project
Because of the automated way in which Heap collects behavioral events, when a customer makes product changes they can sometimes break existing events. This project's goal was to identify such broken events and streamline their repair.
This happened amidst the uncertainty of the early COVID pandemic: like many companies, Heap had reduced hiring targets and, as a result, the design team was understaffed. As VP Design, I addressed this by jumping back into individual-contributor work on this project.
Initial Designs
The problem was already well-understood, so we had no need for up-front discovery or user research. After initial discussion with engineering & PM, I wrote a design brief describing an opioninated solution. Then, as engineers began scoping, I moved on to mixed-fidelity designs.
The Design Brief was a type of document I created at Heap to address a handful of common design-process challenges--most notably, the tendency of design teams to design too much, at too high a fidelity, too early in the process. This project helped establish the value of design briefs as a low-fidelity way to evaluate key trade-offs and permit rough, early engineering scoping and leadership review. More on design briefs →
Twists & Turns
The engineers soon hit a snag: due to some aspects of our data model, my solution--while still effective from a user standpoint--would dramatically increase project scope beyond their initial estimates.
They proposed a quicker implementation path. It seemed like a reasonable compromise to me, and I created a new design brief.
This was a fantastic example of why design briefs are valuable: all of this happened before I'd expended significant design effort.
UX Risks
As I fleshed out the revised design, I became concerned about a UX risk--a part of the flow when users could become confused and fail to complete their task. I put together a quick usability test, and the confirmed the problem.
Our Director of Product was skeptical: how did we know it was worth the effort? I'd created a "Product Quality framework" to help us have more structured discussions around this sort of trade-off, and it turned out to be just what we needed to move the conversation forward. We agreed to fix the problem.
Reflection
- Frameworks can provide a powerful way of reducing the apparent fuzziness of design, for designers and non-designers alike. And for a framework to be useful, it need not make things quantifiable; it only needs to make them more concrete and aid in structuring the conversation.
- Occasional individual-contributor work can be valuable for a leader, to avoid lost skills and ensure empathy with the day-to-day activities of the team.
- As a solution to understaffing, jumping into individual-contributor work can be effective. But take care: when overused, it could prolong the staffing issues at the cost of leadership burn-out and reduced management effectiveness.
- I've always liked low-fidelity artifacts; Event Repair helped establish the design brief as a powerful one.