The Detail Trap

Details are important, critical even, attention to detail differentiates good from great products.  There is an odd paradox about product design though, people notice the details first not ‘good design’. Recognition of a good product experience only comes through usage, it’s one of the last parts of the product lifecycle to be appreciated. Conversely, it should be one of the first to be considered. We, the product designers and developers, are no different to our users.  Attention to detail is a key trait, it ensures we ship quality. That said, a good development process starts with the big picture and iterates towards that vision, adding focus over time. This post is about one of the most common traps I see happen in the early stages of a product’s development:

Focusing on details: Bad.

Just keep swimming: Good

A project is a journey, it has multithreaded paths; System architecture, Workflow design, UI design, etc to name but a few. To make progress you need to chose the most appropriate path and step to take at any given point in time.  To take the journey analogy a little further, the steps at the start of the project are usually larger.  Teams are answering the big questions; Who are the users? What are they trying to accomplish with this product? Which features can we deliver on schedule?  These are critical questions but answering them doesn’t always feel like progress is being made.  We are paid to create prototypes, write code, test.  Writing a use case document or drawing some boxes and arrows doesn’t always feel like progress. This is why we often tackle the first tangible problem that comes along just so it feels like we’re making real progress. Questions like “Does this option belong in ‘properties’ or ‘parameters’?”, “should the labels be left or right justified?”, “we need a better name for this feature” can wait, they’re easily changed.

Knowing when to address details takes experience, in lieu of that experience here’s a couple of little tricks I use to ensure I’m making optimal progress on a project.

1) Embrace your inner ADHD child! ‘Details’ inherently require attention and careful deliberation. Getting them right takes time. If I notice myself pausing on a problem early in a project I step back to make sure there aren’t other ‘easier’ problems or questions that can be quickly addressed. If there are no other low hanging fruit then I’m probably working on the right problem. However, if there are big unanswered questions and I’m currently worrying about aesthetics then I might be focused on the wrong part of the design.

To put it another way, a painter starts with broad strokes, the outline of their subject, and increasingly adds detail. Similarly we start with abstract representations of workflow in diagrammatic form and low fidelity mockups before moving on to high fidelity compositions that are connected together in to interactive prototypes. The former is quick to create and easy to change, the latter is dependent on that solid foundation.  The trick is understanding the big questions and having them to hand when you get stuck on a detail.

2) Make alternate designs. It’s good practice to explore alternatives but some interesting things happen when you do. First, you will find yourself jumping between each concept rolling ideas back and forth and keeping them all at a relatively low level of fidelity, thus avoiding stagnation. Second, the alternatives will provide for a more productive discussion in a design review. Given options, reviewers compare and contrast the benefits of each design. Given one design, they will invariably focus on what the design does not solve, they will assume this is the proposal and focus on the details.

Creating alternatives, be they workflow diagrams or paper prototypes, early in the project helps keep the fidelity low and changes less costly. Follow the T design approach, go broad early and then deep after review. The Buxton Pugh diagram explains this better than I can



Moving quickly at the start allows us to rapidly evaluate options, fail early and often with low risk. More importantly, avoiding the details before their time gives us broader perspective on the design problem. We’re more able to step back and see the wood for the trees. Conversely, dialing in an awesome interaction that will be deep within the UI does not mean the over all user experience will be better.

So, the next time you’re at your desk or collaborating with your team and you see things disappearing down the Detail Rabbit Hole™… ‘Parking lot’ it and move on to another big question.




Leave a Reply