Another in my occasion topic of unglamorous design strategies. See also Following as a design strategy

Design strategy is risk management. Delivering product is full of risk and how we design affects that risk.

The number one goal of an early startup product team has to be to deliver good (enough) product fast, get user feedback and iterate. Complexity, ambiguity, surprises, and cognative overload in the delivery process are velocity killers, we must design defensively to avoid them.

The deliver > feedback > iterate cycle should take precedence over better experience where better comes at a cost of slowing that cycle. Iterating will lead to better experiences and product outcomes. This means we are likely to design simpler, more easily deliverable, features than we could imagine.

The strategy is is to create the most deliverable designs, not the best. Or rather – the best designs with the least risk.

What does “most easily deliverable” mean?

This will be very local to your team and product. The designer must know the skills of the delivery team and the likely technical challenges in implementing a feature. There are likely two potential pinch points 1) the quality of designs and the skills and capacity of the design team, and 2) technical complexity and the skills and capacity of the engineering team. Understanding both of these will help guide the ‘defensive constraints’ of the designs.

One example from my time with Thread is to avoid map interactions wherever possible. Thread’s UNITI asset management software is highly map-centric. With maps being a key interaction area, richer map interactions are likely to lead to the better user experiences. But we also know from hard experience that maps have highly complex interactions, are technically complex, and easily become a time-sink eating away at precious velocity and runway. So to design defensively we needed to keep as much interaction in basic HTML elements as possible, avoiding complex detailed map interactions. Slightly less intuitive, much less deliver risk.

Similarly we needed to make major updates to our inspection review tool – one of our key features, and a complex one. Users would spend hours working in the review tool, it’s productivity tool that needs to be learned. As such modelling it more like a desktop application with context-relevant panels and menus that appear where you need them is an obvious direction. But as a design team we had 8 days of one person to take our new user insight and create a fully refreshed design. Going the application route was beyond the capacity of our team. It would have left too much unexplored and carried too much risk of unknowns and surprises into production. We could iterate from something working, but only if we had something working – we couldn’t risk unexplored issues breaking our user’s productivity.

Everyone hates MVPs

They say they don’t but they do. It’s not just leadership who ‘don’t get it’, it’s everyone, designers, developers, PMs, users. No one wants to work on an actual MVP for long. No one wants to deliver the minimum. It sucks. And it’s just draining to continuously discard so many good ideas from so many creative and inteligent people. It will rip teams apart from the inside if you aren’t very careful.

This is the risk of a defensive design strategy.

So yes, use defensive design when you need too.

Ultimately, in a resource or capacity limited team being defensive in your design delivery strategy can mean you are able to be more ambitious in your strategic design and vision. You can move further faster.

But make sure you have a plan to deal with the things that you are defending against. Because it isn’t sustainable.