The message is in the model

Earlier this year I was working with a small team to develop a new tool that helps creatives in the advertising industry do better work. As with any ambitious new product, the roadmap and backlog were crammed with work. New features were often spoken about in the abstract, scribbled onto Post-it notes and stuck onto a sprint in the not-too-distant future.

As experienced consultants we knew the reality was that large features and complex problems needed to be thought about and discussed early on—way ahead of developers beginning to write code. The reason for early deliberation was simple, clarity and alignment on an idea saves wasted effort. The enemy is abstraction and ambiguity. If you come up against features written on Post-it notes in your project then it should be the first sign that you have some work to do to align the team’s thinking.

There are a number of tools that product teams can use to bring clarity and alignment on an idea. They range in complexity from sketches to functional prototypes. We used a range of techniques in our project and I wanted to share them and reveal how they helped us solve our problems.

The word ‘saving’ was being bounced around a lot. We believed that giving users the ability to save inspiring work to “boards” would add massive value for users. “Just like Pinterest”, we’d often say. Though we quickly learned that what we should have been saying was “not quite like Pinterest”.

Our product was very different to other inspiration gathering services. Though we’d love for our users to mimic the same magpie-like behaviours that commonly seen on Pinterest, we realised that saving on our product needed to work quite differently. All of this would have remained a mystery if we hadn’t taken the time to define what saving meant for our product and align the team’s thinking.

We created task flows that, as the name suggests, represented tasks that users would go through to accomplish their goals of saving, organising, sharing, and deleting. For clarity, we drew thumbnails of pages and icons in Keynote. It took about a day to think through and create 14 flows like the one below.

These task flows enabled us to get sign-off from stakeholders, write and estimate stories with the development team, plan the design time required, and ultimately decide when on our roadmap would be the right time to focus on building it. All this was accomplished before I opened Sketch to design the thing.

This diagram differs from the task flow because it takes into account an entire end-to-end journey and reveals complexities in the system. We used this method for having in-depth conversations with the client about how registration would work. It was complex because we had account for multiple back-end systems. At this stage, where one system ended and the other began was still being defined. This model helped us get to that definition whilst focusing on the user’s experience. We asked questions like, how many steps would this take? and, how many form fields will they need to fill out?

With every new feature the shape of our product continued to change. At various points in the project we found it necessary to create system models that gave the team an zoomed-out view of our work.

The system model solved three things, it communicated what we had already built, showed us what we had yet to build, and revealed how it all connected as larger system.

Halfway through the project we knew we had far too much work than would fit into the remaining sprints. Simply telling the client this would have resulted in multiple meetings, deliberations about various features, the size and complexity of them and so on. It would have been a mess and would have costed the team a lot of time—time better spent building the thing.

To avoid the back and forth, we devised a session that aimed to achieve the following:

To do this we created 30 or so feature cards that detailed each possible feature and an estimation of its complexity. Some features had alternative options ranging in complexity from easy to hard. We gave the client a total points allocation based on our remaining sprints and asked them to work through the cards prioritising which should be done first.

In a way these cards aren’t that much better than the features on Post-it notes I mentioned earlier. They’re still relatively abstract with not much definition but when used as part of a prioritisation exercise they played a vital role in helping us shape the roadmap.

When you see diagrams like this they seem like an obvious way to communicate an idea or data. What I found though is that you don’t realise you’re going to need these diagrams until you attempt to communicate a concept to someone else. Often in preparing for a presentation to the client, I’d rehearse my rationale for a design and realise that to properly communicate the problem and all of its complexities, I was going to need a diagram.

In this particular example I needed to ensure that the stakeholders in the room held in their heads the same relationship tree of advertising agencies and holding companies. Once I had everyone aligned on that, I could then use it to explain how our data related to the tree and what it meant for how we were designing the product.

The diagram isn’t rocket science but the way it was used as a tool for aligning thinking was crucial to getting buy-in for the way we wanted to approach building a core feature of the product.

At times I felt that creating some of these models was going to take as much effort as it would to just design the thing. However, it’s important to remember that aligning everyone’s thinking early on will almost always save you time in the long run.