As we mentioned earlier on the blog, we’re working on a very big and ambitious project to create a new city modelling platform, Witan, with London as the first test bed.

Since there is so much that could be done in this field, and so many possible ways to do it, there are some tough choices for us to make, to ensure that the platform works and is widely adopted, both in London and in other world cities.

We wish that new product development was predictable - a straight line from seeing a user need, to building a tool which meets that need, then selling it to lots of other similar users. Unfortunately, it’s rarely that simple or predictable.

There’s no easy way to make that path predictable - but we can do things which reduce the overall risk, and this is a big part of our lives at the moment. This post outlines how we’re tackling the challenge for Witan, drawing some inspiration from the stellar resources shared by the GDS with their user research method wiki, how companies like Spotify build their products, and good agile (with a small A) practices.

Understanding the problem first

If we start by casting our net wide early on, we can improve our understanding of the problems our users have, to end up with a larger set of user needs.

We can’t serve every need, so we validate and prioritise which needs we want to meet with further research. At this point we focus on the problem, not on how we’d solve it.

Choosing the smallest way to meet a need

When we  have a smaller set of needs we’re aiming to meet, we diverge again, to come up with solutions to the problems we’ve decided to target. We’d typically describe these as user stories.

Checking we’ve actually solved it

We choose the smallest subset of user stories possible to deliver to users, build a solution which meets those needs, and see how well it works for the users in reality. When we’re building those solutions, we use multi-skilled teams because we want to minimise handoffs between experts, and we get our team to work with directly with users in order to create a sense of empathy and make sure that the technology really meets their needs.

And repeat…

Inside Mastodon C, we’ve been working in weekly iterations for a while: each week we demo what we’ve made, and then we plan what we’ll do the following week. One key thing we’re trying now, is using the mental model above to decide what activities in our ‘toolbox’ are most appropriate for that week.

Early on - when our focus is discovery

Early on in the project, most of our time is spent generating ideas, and exploring them, so we have a set of needs to validate, most of our activities are in the left hand side of our ‘toolbox’.

As we learn more, we’ll move more of our efforts to activities in the middle, where we’re validating our understanding of user’s needs, and see how they currently try to solve their problems themselves. It’s not uncommon for some of our team to focus on activities on the left after discovering something new, while the rest focus on the middle, on problems that we have a better understanding of. Again, we share what we learn each week in a show-and-tell like session, (but with added cake).

Later on, when we’re confident we understand enough of the problem to build a solution to it, we’re likely to be spending most of our time on activities on the right.

That is, until we discover something interesting enough to warrant spending some time using tools from the left hand side of our toolbox again. In some cases, we might discover a killer new feature that makes sense to add to what we have built already.

In others, we might discover the beginnings of a new product that is interesting, but not key to meeting the needs of the users we’re designing for right now. We’ll save it for later to see if it comes up again, at which point we’ll make a call about whether we should investigate further.

Well, that's the plan at least

We’re working on one of the most complex problems we’ve ever come across, in one of the greatest cities on earth - if you’d like to see how we get on, watch this space.