Simple answers… not always so simple

Recently I’ve been asked the following question a few times, and I wanted to share my take on the answer:

“Why do designers sometimes go into a lot of detail with designs when we’re just looking for a simple answer?”

It’s one of the challenges most of us design-folk (wherever you sit in that umbrella) often come up against in one form or another, but more recently I’ve experienced a direct curiosity and/or challenge regarding the care and attention given to “irrelevant details” and need for different levels of granularity.

Simple answer… sometimes it’s necessary.

There are often complexities, curve-ball needs and behaviours, and unexpected technical or business constraints which are hidden, causing what feels like a simple question to be only the beginning of the story. As designers we can use different levels of granularity to tackle different challenges and look at things in different ways, this can help us to spot these things early.

A 10,000 ft view

10,000 ft views help us to support overarching decisions, high level assumptions and discussions about end-to-end journeys, service dependencies and overall customer experience.

Inevitably these discussions, more often than not, quickly escalate into detailed questions about “what if people need to…?” (people being business or users in this instance). By going through the definition phase of design and understanding the problems in detail we can address those concerns head on, earlier. This 10,000ft view can help us to give key stakeholders and decision makers a high level concept to point at as a reference. It’s always a better place to start, rather than relying on the assumption that what’s in everyone’s heads is the same picture.

A high level view is a quick and safe space to be wrong in; allowing stakeholders to call out and (sometimes literally) point at where the misconceptions, gaps and constraints are early on.

Another application of a 10,000ft view is that it allows us to start with the end game or best practice journeys to see both the wood, and the trees by kicking off with a “happy path” for our primary user type. We can then begin to ask the “what if” questions, challenge the assumptions and try to resolve key pain-points we find along the way.

More often than not this is a tool I use at a service design level to quickly communicate the touch-points across both the business’s product ecosystem and the external touch-points and triggers for their user-base. However, at a product level this feeds into or defines the logic required for behaviours / rendering of components, content, actions and even layouts.

Digging into the detail

Asking and understanding the “what if”s help us as designers to understand and identify potential surprises, pain-points and opportunities for various levels of detail across the product design and implementation. Highlighting early-on, things such as:

• Gaps in propositions
• Possible impact on architecture for now, next and later
• Dependencies on other services / 3rd parties
• Data flow requirements and concerns
• Inter-dependencies on journeys, tasks and interactions
• Unique experiences or essential functionality for specific user types
• Supporting product strategy decisions about priority of deliverables
• Scalability of business and user requirements
• Balancing business and user needs
• Catching potential jump off points early
• Behaviours for components, pages, processes and end-to-end journeys
• Reducing duplication of effort for the business across similar journeys (ie different read / write / share / download permissions)
• Business logic needed
• Where smoke-and-mirrors can give the illusion of something ‘for now’ / ‘forever
• Opportunities for “delight”, advocacy driving features and functionality

Helping to define the problem

As an ideal, a huge portion of design work (I’ve seen 70–80% used often) is finding the problem we’re trying to solve and understanding the “so what” and impact on solution of the insights found and given to us via research and testing.

It’s hard to find a good solution (or any really) until you have a clear idea of what the problem really is; by understanding the whole picture (at least for our primary users and the business) we can reduce the risk and cost of needing to fix “real problems” later.

By both digging into the detail and establishing a 10,000ft view early as part of the discovery and definition phases of design help us to utilise as much of the evidence, information and expertise as possible. This enables us to design the features and functionality required whilst understanding the 360 (or as close to it as we can get!) of experience for both using them in isolation and tying them together as a “journey” or “task” for the people using our product.

In conclusion

A combination of granularity and understanding the details is a good way to understand, capture and articulate the problems were designing for, plus a lot of potential, risk and logic early on in the delivery cycle.

In my experience, in a single track Agile environment there can be some significant risk to the details if there’s no capacity, time or money to get research done upfront, but I’ve found that capturing assumptions and raising risks early a way to keep everyone on the same page from the start.