Inception
Ricky Morris
Ricky Morris Product Analyst and Designer

Our Thinking Tue 26th July, 2016

Start out right: the importance of Inception

Having taken part in numerous Inception periods in my time as a UX Designer – and fresh from helping to run one for a new Equal Experts client – I’ve had ample chance to develop an appreciation for just how vital Inception is to the success of any engagement.

Inceptions are all about making sure the client and project team have the same understanding of the problem to be solved. It’s about over-communicating the information around the new project via an intense period of familiarisation. It’s all too easy to underestimate the hidden contexts in your initial conversations or observations; Inception is about driving any assumptions out into the open, so a project can start on the right foot. Done right, it will set the tone for productive, collaborative, and analytical communications – and maximise the project’s chances of success.

While there’s no one single approach to Inception, there are some general steps to follow – and a general shape to the whole process. As Inception progresses, the team moves from abstract, broad conversations into gradually more detailed discussions – ultimately capturing the fine details of what will happen next, and the work that must be completed to accomplish your agreed-upon goal. Below, I’ve outlined the key steps in an approach that’s worked well for us on several projects.

1) Keep an open mind

The first step is actually more of a principle: it’s very important to keep an open mind throughout Inception.

One risk factor for the process is that the client (or a particular stakeholder) will often be attached to work they have already done, prior to your involvement. Whether it’s research, their own opinion or something else – they may believe they already have the best solution formed and ready in their minds.

However, Inception is all about resetting any sense of already knowing what needs to be done, and it’s very important not to anchor your expectations of what the eventual solution will be too early on. Try to let go of any pre-conceived notions before or during Inception and let the data inform you; every morsel of information can then be used to revise your ideas. Try to state and re-state the problem you are trying to solve as a team before accepting a proposed solution: there’s nothing more frustrating that working on the wrong problem!

One metaphor I’ve found very useful for Inception is to come to it as an artist might when working with a new material, like clay or fabric. Inception is the opportunity to learn about the properties of this material, how you can work with it, what its limitations are, what the organisation simply won’t permit. You need to know these things before you can fashion the material into something beautiful.

2) Start with Impact Mapping

I can heartily recommend the Impact Mapping approach pioneered by Gojko Adzic.

An impact map helps your team map out the goals you’re setting out to achieve, who your stakeholders are, your teams, and eventually your backlog of work, too. It’s critical to have a shared understanding of all these factors, and creating an external map which everyone can reference helps you focus on the important questions:

  • WHY are we doing this? What’s the problem we’re solving, and why does this help the company and its customers?
  • WHO can help us – who are our stakeholders, our team? Who will stand in our way?
  • HOW will each stakeholder help the team? What impact are we aiming to make in the world?
  • WHAT will we deliver? What is in our power to do to make the impact above? This forms your backlog.
  • WHEN – once you have your backlog, you can start estimation and prioritisation and begin to understand timings

The first of these questions is particularly important, because the problem will often not be what the client thinks it is. In general, never stop asking ‘why?’ – repeatedly asking why is the way to drill down to the heart of a problem and understand why something is really worth doing.

As you answer the questions above, you’ll be able to build an impact map that traces every last piece of work back to your original goal. It gives each task a thread back to your overall goal, and will later be a critical framework to help you stay focused, and push back against scope creep.

Impact_map

Creating your impact map will also give you an idea of how the client organisation is structured, and how the client thinks. As Conway’s Law dictates, what you build will invariably end up reflecting this (for good or bad), so it’s good to be aware of it up front!

Happily, the Impact Mapping approach is open source – you can find plenty of helpful materials and support at impactmapping.org (and I can recommend the book, too).

3) Turn on the information firehose

It’s only at this point – with your map in place – that you should invite your client to tell you everything about its business domain. Relevant background information, research, marketing materials, presentations, competitor analysis; ask for all the information that could possibly be useful.

This allows your project team to learn all the terms of jargon, customer marketing segments, important concepts and so on that the client uses. And once you have the information, you can overlay it on the overall picture provided by the impact map. Some will be useful background information and some will be directly relevant to specific aspects.

With this done, your team is now in a place to precisely define the problem it is trying to solve – and only then can you start considering the solution.

4) Map out user journeys

Now you know the environment your product and service will be built in, you’re in a position to map out all the different journeys your key customer types might make through your eventual solution.

I recommend using behavioural personas here, allowing you to focus on distinct categories of behaviour that the client’s customers fall into. In the Inception period, you may well only have time to focus on one persona; if so, focus on the most important one (or the most well-researched).

Bear in mind that all customer types will have goals that extend beyond your client’s product or service; the interaction between the customer and the solution you create is part of a series of activities which move the customer towards their actual goal. The beliefs, skills, mental models, prior experience, and aims of the personas will differ, and you should ultimately capture journeys based on each one – so you can design to support all the different behaviours required.

When you’ve done this you’ll have the big vision of what you need to create, even if you can’t do everything right away. But that’s what prioritisation is for! I recommend doing a quick prioritisation of the features you add to your user journey before you start, putting each valuable chunk of functionality into three categories: now, next, and later. These roughly translate into three levels of complexity for an entire end-to-end version of your solution: a minimum-testable ‘steel thread,’ a version which is actually launchable, and the ‘nice-to-have’ features which would really help your product stand out.

5) You’re ready to start

You now know what you’re building, who it’s for, and you can demonstrate why each and every part of your proposed solution makes sense in relation to the stated goal(s). That’s a great starting point, and since, in my experience, misalignment of expectations and miscommunication are the biggest threats to a product’s success, hopefully you can see why Inception is so valuable to the success of a project.

Inception puts you in a position to start work on an end-to-end slice of functionality for your product – a minimum testable solution. This walking skeleton is the smallest thing you can build which demonstrates the fundamental concepts of your solution, and validates the end-to-end value of your proposition. It lets you confirm whether you’re solving a valuable problem and de-risks the biggest technical challenges your team will face.

Once that’s built, you can demo your concept and get feedback from real end users. You can validate (or invalidate) assumptions and personas, and feed your insights back into the design. Before you know it, you’re up and running – with a great idea of where you’re heading.