The design process is infinitely adaptable. At a distance, the way to design a city, a house, a kitchen or a toaster is the same; explore and identify the goal, imagine solutions and refine them until you have something that can be built.

The double diamond is the simplest abstraction of this process, but rather than the hardness of diamond, to me the texture of design is more like dough. To be worked and shaped while staying together, it needs the right amount of flexibility.

At Cecil, this flexibility comes from balancing a firm overarching process, with looseness in the detail. We’ve found a process that suits our needs as an early-stage B2B SaaS product, with a remote, distributed team.

Here’s the basic outline we’ve been following for the last 6 months:

  • We reprioritise the design backlog every 6 weeks. Then, for each project...
  • We define the job to be done and the problem to solve
  • We explore options and design the solution

At this level, pretty much anyone in the team can tell you how design works at Cecil. This is intentional since the design process is the engine room for delivering customer value – something the entire team is invested in.

Product people and designers may see shades of Shape up, Intercom’s Job Stories. Truthfully, it’s a chimera of design process playbooks. A patchwork to suit our needs, our pace and our people.

1. We reprioritise projects every 6 weeks

Every 6 weeks, no matter where projects are at, we pause and reset. This means some projects are shipped, some didn’t get as far as we wanted and some never got started.

We do this so that we’re always working on the most important things, given our immediate needs and those of our customers.

Source: Sean Batchelor

Prioritisation starts with reviewing our inputs board. This lives in notion and is the reservoir for all customer requests and suggestions, team observations and ideas. Inputs come from intercom chats, customer checkins, dedicated research and analytics.

Inputs are grouped into themes and loose projects are defined for us to prioritise. The current prioritisation criteria is aligned with the levers we believe will make Cecil an indispensable tool for our customers.

Source: Sean Batchelor

As an early-stage product team, we’re balancing the prioritisation of improvements for the satisfaction of daily users with making progress on our broader product differentiation and vision. So, alongside ‘build’ projects where the output is product requirements, we run ‘discovery’ projects, where we seek to make progress on a higher level, less well defined problem and value proposition.

2. We redefine the job to be done and the problem to solve

Source: Sean Batchelor

We receive a large number of feature requests and suggestions from customers. This is an invaluable resource for customer insight, but implementing solutions directly will dilute and delay the pursuit of our product vision.

To deal with this we treat requests as signals and start by exploring the underlying problem.

Whilst each project brief includes a starting hypothesis of the problem, we re-trace our steps to ensure we have understood it and know how a better solution will be judged by our customers.

We review feedback we’ve heard to date, look at platform analytics and conduct targeted customer interviews. The output is a rearticulation of the Job to be Done, the frictions impacting customer goals, and the impact of that struggle.

The process is a mix of art and science. It’s an imaginative exercise, to put oneself in the shoes of another, then an analytical process to draw a boundary around a meaningful problem, and set the right frame for solutions to be found.

3. We explore options and design the solution

Like archers, having drawn back the bow, we load multiple arrows and let them fly. It’s time to think about solutions.

Source: Sean Batchelor

Problems and solutions have a one-to-many relationship. To pick the right option, we play out different solutions in prototypes.

Prototypes could be a few Figjam stickies, a rough sketch, a Figma prototype or a partially integrated bit of front end code. They’re all are kinds of speculative mockups that simulate alternative realities.

If we’re confident in the problem, a simple enough solution can usually be found to ship, so that we can learn. Customers are the ultimate judge of a solution, so we don’t labour decision making.

It’s also important for us to keep solutions simple so that they don’t create design or technical debt and introduce less variables that might have unintended consequences.

Design at the heart

At Cecil, the design process is at the heart of the product, where strategy is converted to features in the hands of users. We believe a human-centred, collaborative approach to solving problems will lead to better product and a better chance to succeed in our mission to be the operating system for natural capital, helping teams regenerate nature.

Share this story