Product shearing layers and the "double-diamond" approach to design

The organising principles of agile are based around the needs of developers. So processes and systems are broken down into units of functionality and fed to development teams along a pipeline of delivery.

We all know that estimating big tech projects is a crap shoot, so the focus with agile is on just in time decision making, problem solving and optimising through-put. With so many unknowns this is a much more rational and realistic approach than trying to plan and estimate everything up front.

Unfortunately, while this organising principle performs well for developers, it can be problematic for designers who need to tackle things as part of a coherent system, rather than a series of functional chunks.

Agile allows for iteration, so one way of tackling this problem is to give in to the inherent uncertainty and allow the design to emerge over time. So you slowly end up aquiering design debt, with the hope that you’ll have time at the end of the project to bring all the disparate pieces together. Sometimes this happens, but often this gets relegated in favor of more functionality.

I believe this is one of the reasons why so many established tech companies struggle to produce a holistic user experience and end up creating a disjointed UI instead. Lots of small pieces loosely joined rather than a coherent and considered system.

Lean ux has attempted to add a layer of design thinking to the process. However the minimal shippable unit is still based around features rather than systems and stories rather than journeys or experiences.

With this method experiments are run in the wild on real users rather than on paper. This has the benefit of giving you real rather than aproximated feedback. However it can also lead to significant amounts of technical debt and a poorly considerd product in the hands of your users for longer than is absolutely necessary. This probably doesn’t matter in a new start-up with just a few users, but can be much more damaging for an establish company with millions of customers expecting you to deliver of your brand promis. How often have we seen the MVP end up being the final product?

By comparison, the traditional UX approach sees problems iterated on with paper and prototypes rather than live users and working code, allowing you to iterate in a faster and more cost effective way. The trick is for these sketches to remain as recommendations rather than specifications, which is often not the case.

Of course these two approaches aren’t mutually exclusive, but I’d like to see Lean companies do more of their learning with prototypes and less at the expense of real users. Not everything has to be deduced from first principles, and there is a huge canon of design knowledge to draw upon here.

The tension between design and development reminds me of the famous shearing layer diagram which Stuart Brand used to explain the different speeds at which buildings evolve - the interior moving faster than the shell.

While developers find it easier to break off pieces of functionality, encapsulate them and then tie everything together as they go, designers require a higher vantage point in order to map out the entire system to do their jobs well. The business often appreciates this vantage point as well.

In typical, highly functionality agile environments, a single product will be broken down into multiple product teams with their own product manager, design lead and team of developers which they are tasked with servicing. These smaller “products” will usually focus on “slices” of a user journey rather than the whole experience - another reason why many products feel somewhat disjointed.

The speed of progress is dictated by the speed at which the developrs can ship products, forcing designers to operate at a pace which they’re often uncomfortable with. This also forces them to focus their talents on production and delivery rather than strategic thinking, which may be fine for junior designers but can be both isolating and demoralising for more experienced practitioners.

Ironically, a small group of designers are usually better able to service the needs of a large number of developers by working as a team across the whole proudct, rather than being separated out into individual product teams. However this approach is often branded as “waterfall” and dismissed by many agile proponents.

Now if you have a fairly unreconstructed design team who are more comfortable dictating rather than collaborating, they may have a point. The goal here isn’t to hand a spec document to the Dev team in the form of a set of wireframes or working prototype and simply get them to build what you’ve specified without question.

However I do believe we’re entering into a post agile world where prouduct can adopt the best parts of waterfall and agile, without having to pick one or the other and stick to them dogmatically. Instead, let’s be aware of the differing shearing layers and adopt and approach that works for all parties.

In his recent IA Summit talk, Peter Merholz spoke about the “double diamond” approach, which is the method I personally favour.

At Clearleft we typically undertake an initial definition phase where we talk to the business, interview potential users, develop a product strategy, sketch out the key user journeys and create the basics of a design system. This system isn’t set in stone, but provides just enough of an overview to set the general direction and avoid us aquiering too much design debt.

During this initial phase of the project, the team can be fairly small and efficient. Maybe just one UX designer, one UI designer and one creative technologist. We can test ideas quickly on paper or with low fidelity prototypes and discard work that proves ineffective. We’re iterating, but at a pace dictated by the needs to the product, rather than the artificial tempo of a “sprint”. We’re not looking for perfection, but hope to get the main design problems finished to a level of fidelity all parties (business and tech) are happy with.

Once the plan is fleshed out, we’re more than happy for the tech team to work in whatever way best suites them, be that Scrum, Kanban or some other variant of agile. With a better understanding of the whole, it becomes easier to break things down into chunks and iterate on the individual stories. Designs will change, and the language will evolve, but at a pace that works better for both parties.

This “double diamond” approach places the needs of designers at the forefront of the first “diamond” and sees them leading the initial strategic enguagement. The second “diamond” flips this on its head and sees design servicing the needs of development and production.

I’m sure some people will claim that this to be part of the agile canon already, be that “iteration zero”, “dual track agile” or some other methodological variation. For me I really don’t care, just as long as design gets to dictate the process during the formative phases while development drives production.