A dogma-free approach to leaner UX

A 7 minute read written by Phil July 16, 2015

An illustration of an arrow going directly through a maze

There is a time and place for unwavering “rules of engagement.” I want my surgeon or pilot to dogmatically follow the predefined process. There are also times when a little chaos can shake up the order of things – for the better.

At Yellow Pencil, for example, we’ve been reviewing our process and looking for ways to be more efficient and better at what we do. This is an ongoing process and has me thinking about how I work and where I can add more value and be more effective.

We’ve all heard the familiar refrain: if I only had more time or budget I could have done so much more. Well, three of the fundamental constraints on every project I’ve ever worked on are time, budget and quality, and adding more of each is seldom an option. One way to tackle this problem is to rethink your approach and become leaner with your process.

This means moving away from a documentation-heavy waterfall process, in which we spend lots of time designing and documenting everything up front and then handing it off to the development team and hoping it can all be done in the time left over.

The waterfall process provides a better sense of certainty at the cost of inefficiency. One of the reasons it is so inefficient is that there is a need to maintain large amounts of documentation and continually revise and update documents as the project moves forward. A simple layout change, for instance, can mean making lots of small changes across multiple screens, managing wireframe and design comp versions, and hoping that you haven’t missed any changes or introduced inconsistencies in the process. This approach allows you to be very clear about what you intend to build up front, but it also pushes all of the risk into the final development phase.

I think there is a better way that is more true to the inherently messy and chaotic nature of the design process. After all, I want to focus on solving problems and addressing user experience concerns rather than just updating documentation. Taking a leaner approach allows me to do more valuable work and be more efficient in the process.

Think leaner

As unintuitive as it may seem, the more constraints you have, the easier it is to be creative, because the imposed limitations enable you to focus on the core problem and concentrate on working through it, rather than staring at a blank piece of paper waiting for inspiration to strike.

Taking a leaner approach to my project work means embracing the constraints and working creatively within them to find and build the best solution possible. I like to think of a project as a journey from confusion to clarity, rather than a laundry list of UX, visual design, content strategy, and development deliverables.

I try not to think of the documents I produce as formal, finalized deliverables, but as a way of communicating what I have learned to the client. I focus on generating discussion and adding constraints, challenging assumptions, and visualizing user or business problems so that our solution better meets everyone’s needs.

With learning and discussion as the focus of these activities, rather than deliverables, I have more freedom to adjust the approach and only put enough effort into a phase or deliverable to learn what we need in order to move forward to the next phase of a project.

Start with a plan

Before we can start designing or building anything we need to know what we are building and for whom. This means having some clear and open discussions with our clients about the problems they are facing, either from a business or user standpoint. We also need to know how much of a priority each of these problems is, so we can better determine our approach to ensure that we get everything completed within the time and budget available.

There are a number of ways of getting this information and documenting it: UX workshops, user story mapping, MoSCoW lists, or other techniques all work, and the most appropriate approach often depends on the project and client.

We like to come out of discovery with a defined a Minimum Viable Product (MVP) – or as Paul likes to call it, “Minimum Viable Loveable Product” – and a list of detailed user stories that cover the core functionality and acceptance criteria.

Now that we know the audience and the problems we need to solve, we can start the process of designing and building the solution. This is where you can decide on a philosophical approach to agile or lean, but for me this boils down to adding the most value to the project with the least amount of effort.

Fidelity vs. certainty

The easiest way you can add value to a project in the early design phases is by iterating quickly and minimizing the effort put into the work. How? Sketch out your ideas and concepts, and share them early and often. At this point you are just trying to capture screen flows, rough wireframes, core pieces of functionality, and have conversations with the team and the client.

When I say sketch, I mean sketch. Rough, messy, imperfect – not precious pencil designs that take hours to complete. Sketches should be quick, allow direct input and feedback from everyone involved and are open to discussion and improvement. They allow you to get alignment with the team and client, validate initial approaches, and quickly iterate through different concepts at low fidelity before anyone is completely committed to the idea.

We have created interactive prototypes using sketches and tools like Marvel and Invision. This is great for validating screen-flows and identifying gaps without any major investments.

Refine where needed

Now that you have validated your sketches and approach you can start to add fidelity where it’s needed. The goal is to get enough detail and clarity so that the client can sign off on the direction, and the team can continue on the process. Is a sketch of a login screen with two boxes, two buttons and a forgot email link enough to move forward? If yes, move on. If no, refine.

What refinement actually means depends on your client, project, and team. It can mean more detailed sketches, static wireframes using real content, or quick interactive prototypes. On a recent mobile app project, we built a sketch-based demo using Marvel, then used the sketch app to refine key screens, add detail, and ensure all required elements fit comfortably on each screen.

Build functional prototypes soon

As soon as you can, you should jump into functional prototyping and development. Once you have a solid combination of well-written user stories, acceptance criteria and a collection of “good enough” sketches or wireframes, you should be off to the races.

This is not the end of the UX process; rather, it’s the start of the next phase. Instead of designing each screen, you can work directly with the development team, reviewing the prototype and refining screens and flows as needed. This approach also allows you to start testing and validating your approach with actual users, while there is still time to adapt your approach.


Two heads are better than one, and a team will usually come up with a better end product than a group of individuals. I am a huge advocate of collaboration, not only within and across teams, but also with clients.

The key to this type of collaborative approach is communication: we have replaced documents with discussions, which allows us to quickly and efficiently design, build and iterate, starting with the basic functionality and adding complexity as we move forward.

It also allows the team to focus on the core features and functionality first, which reduces the risk of spending time designing and prototyping things that will not make the final product, or investing time in features that prove to be less valuable. We can also work on multiple things in parallel at different levels of fidelity, which gives us the flexibility to adjust the approach and refine features and functionality as they go.

Focus on efficiency, flexibility, and value

I am not a proponent of any particular flavour of lean (and there are lots to choose from). There might be one that works for you, but given the clients, projects and technologies I generally work with, each has its pros and cons.

For me, the key is being more efficient and flexible with your approach and focusing on value over deliverables and conversation over documentation.

We have seen the value for ourselves and our clients, and are still working on improving our process. Being more efficient and leaner in your approach to projects is not something that happens overnight. One of the fundamental aspects of lean is that you keep reviewing and revising your process, looking for ways to improve it.

You don’t need to change everything at once: start small, and focus on being more efficient with some of your key deliverables. Try sketching more and use those sketches to drive discussions and collaboration where you can. As a UX designer, I don’t want to focus on the thankless work of maintaining documentation, I want to focus on solving problems and building experiences – and being leaner lets me do that.

Ready to ditch the dogma for a leaner approach? Get in touch and I can show you how, or share your own UX tips in the comments.