As Cozy has continued to grow, our design team has been focused on making sure that we’re aligning the product roadmap with business goals and, most importantly, what we’re hearing from customers.
But how does an idea actually go from the proverbial lightbulb over someone’s head to a well-designed feature released into the wild? To answer that question, I’d like to talk about our process and how we operate as a design team here at Cozy.
One of our team’s core tenets is that a designer must be able to communicate the design problem and solution, and not just visually. They need to be able to tell the story of the feature as if it were real, before we even create wireframes, comps or prototypes. After all, how can you design something you can’t explain?
We typically start off our Monday morning sessions around a whiteboard with markers, talking about a particular problem. This approach helps us get a high-level understanding of the problem and gauge whether or not everyone feels that the problem is worth solving through design. We begin to synthesize the underlying business strategy with the high-level customer interactions and itemize our system-level constraints (time, platform, etc.)
Even though our products have a relatively small footprint, we work with time-sensitive financial transactions (rent payments), so there is no margin for error. We take turns collaborating on the whiteboard while continuing to define the problem and, at the same time, recording problems the solution does not solve. These discussions are informal and conversational, primarily cognitive exercises to help define the design problem explicitly and to differentiate the solution and non-solution. This is effectively the left side of our design squiggle or our prioritization phase.
Next, we write the design down in paragraph form using a basic outline (below). Before trying to explain (or design) the solution, I find it helps to write down a description of the problem and the solution. Writing before designing helps us define the boundaries of the design and begins to bring the design forward into reality. I’ve found this one-page format works well to communicate the solution in the best way possible to as many stakeholders as possible.
It looks like this:
Why would we want to devote resources to this particular feature? To answer that question we define at a high level what it will do for the business and how it fits into our strategic plan. It needs to fit together elegantly with other features and products, make sense as part of a larger product portfolio, and move the business in the right direction. At a startup, the key drivers are typically growth, revenue and customer satisfaction. We try to hit all three.
What are the anchoring principles for this feature? What are our points of reference when debating the merits of one design solution over another? These principles can be aesthetic (must follow established visual styles), functional (must work independently of core product), experience-based (infer as much as possible from customer input). I find the set of principles gets distilled over time and the overall design aesthetic of the product begins to emerge. The principles become how the team designs.
What are the goals of the customer in the context of the defined problem? Who will benefit from the feature? Is anyone’s experience diminished? What trade-offs are we making?
Imagining that the feature already exists and is being used, we write down scenarios in which hypothetical customers take common paths through the product, interacting with the feature to be designed. These scenarios are the story of the feature in written form, before there is any visual design.
We then define the essential features without which the solution will not be considered production complete. In engineering nomenclature, these are the P0s. If there are too many of these, the overall feature is probably too big.
How will we measure the success of this feature? What will success look like? The answers to these questions inform the engineering and marketing teams where to instrument the feature and how to configure tracking funnels. The output of our instrumentation highlights where our design falls short and begins the conversation with customer support that feeds back into design iterations. This is how we design with data.
We’ll record what we do not know. These may be engineering, sales or marketing constraints. They may be changes in the competitive landscape or may reflect strategic bets we make in the short term. This is useful information as we return to iterate on an existing feature.
Let’s try and not have the same discussion twice, ok? If there is a contentious issue, let’s write down what led to the decision and what was decided so we don’t spend time having the same debate again later on.
The purpose of the outline is to think through and write down the design before we start to wireframe or prototype. The exercise typically leads to more discussion and a firm definition of the feature to be designed.
It’s not meant to be a comprehensive document but rather a tool to help us quickly reach understanding and communicate the design to engineering and marketing. Providing this level of visibility to engineering before we create high-fidelity comps allows them to review the solution without having a discussion about visual style, copy or interaction design.
The benefit of this approach to the design team is that we’ve spent less than a day carefully defining a design problem and creating a story to bring the feature to reality.
The written outline gives us a guide, a prototype in story form. Like the “songline” tradition of indigenous Australians, the story of our proposed feature helps us navigate the vast distance from idea to live feature.
In the next post I’ll talk about how we move from words to visual design, prototypes and production code.