Skip to content
Search
Generic filters
Exact matches only

The 3-lens approach to agile design

A mental toolkit for prioritizing and designing.

Facing a mountain of work as a one-person design team is daunting.

In startup and consulting environments, often a sole person becomes responsible for work that may otherwise be divided amongst product designers, product managers, UX designers, researchers, interaction designers, the list goes on. The vast array of online design communities contain fantastic resources for championing design or prioritizing features but concrete workflows and processes seem to be locked in secrecy.

The world loves to talk about agile and what it means for software development but many seem to elude the ever-present question of, “what should I be doing today so that I don’t cause a catastrophe tomorrow?” This piece presents a generalized approach to prioritizing daily design work as a one-person design team in a fast-paced, agile delivery environment.

The Lenses

Most products are alive, constantly being shaped and molded as the end user’s needs evolve. Rather than discussing project inceptions or closures, this approach addresses the ongoing design tasks associated with delivering software — the daily grind.

All feature work is seen through one of three lenses: the far, the near, and the immediate. As a piece of work moves from a fuzzy idea in the distant future to a pixel-perfect story card awaiting kick-off, it travels through each lens’ field of view.

  • The far lens is like putting on binoculars. User research is conducted, and high-level decisions are made about the future of the product. The goal here is to ensure you’re building the right things.
  • The near lens is like a pair of reading glasses. User stories are prioritized and thoughtfully researched to prepare for the final leg. The goal here is to ensure you’re building the thing right.
  • The immediate lens is like a magnifying glass. The goal is to have a smooth kick-off and avoid re-work. Rework consists of bugs, and unclear requirements; it slows down projects dramatically.


A feature moving through the three lenses

Not only is it important to know when to move work from one lens to another, but also what design work looks like in each lens. Performing design activities that are too specific, too early could result in wasted time. Requirements can change as a feature nears closer to development.

The three lenses require three different modes of thinking. While the far is abstract and creative, the immediate is meticulous and analytical. Context-switching can become exhausting, so the ever-present challenge of time management is of the utmost importance. In the following sections I try to explain when to pick up the magnifying glass vs the binoculars. 


Design work evolves from a fuzzy insight to a clearly defined story

The Far 

Work in the far lens is blurry and often distant. In the far one should constantly question the motive behind features. Does the user want this? If they do, does the business have anything to gain by supplying it? User research takes priority, then synthesizing user research, followed by brainstorming and exploratory prototyping.

Work in this lens is kept in exploratory prototypes and user research findings. The tools of choice for tracking work may be a product roadmap and user research insights (a great method for documenting user research). Work in the far may be implemented in four weeks, or maybe in a year. In order to move work from the far to the near, one must ensure that the feature drives the product towards a business objective by addressing a real need of the end user.

The Near 

Generally, by the time a feature moves to the near it has been divided into stories. In the near, the story is opened up and explored. Key features of the story are illustrated and documented while loose ends are tidily capped. The tool of choice for tracking work may be a story map.

While looking through the near lens, internal and external stakeholders should be tracked down to iron out legal restrictions, data assumptions, privacy concerns, and technical implications. The information architecture of the page is validated, and the functionality of every button is confirmed. The designer should position themself with all the knowledge they need, document it, and leave once they’re confident their handwriting is legible.

The Immediate 

Once a story is prioritized and it’s about to enter centerstage, it’s moved to the immediate. By the end of the story’s journey, the designer should be confident they have sufficiently researched and documented to instill a shared understanding with developers at kick-off. The story kick-off is a vital ritual to ensure developers are equipped with all the knowledge they need to flawlessly implement the story.

In the immediate, stories are dissected. Every word on the error message is correctly capitalized and every icon is exported for handoff. The tool of choice for tracking work may be a Kanban board or a story wall.

In Practice

When working on a small software delivery team, there’s usually one clear bottleneck: development. Designers can move shapes around on a mockup all they want, but it takes time for developers to work their magic. It’s imperative that as soon as a developer pair finishes a story, there’s a new story sitting on the conveyor belt for them to assemble. This is why every morning the magnifying glass should be picked up first to ensure the next set of stories are ready. Then move to the near to ensure the next batch of stories are prioritized and ready to be moved. Only then are the binoculars picked up to examine the far.

This is the piece that some find counterintuitive: while

features move from the far to the immediate, designers

should move in the opposite direction.
The secret sauce to formulating a well-weighted day is found in the team chemistry. Constant communication with the team lets designers gauge the velocity of developer pairs. Suspecting a pair has a couple of large tasks ahead of them which are pre-packaged and ready to begin, the day is suddenly free to interview users or reorganize the roadmap.

I’ve been slowly developing this approach but the thoughts all came together during a recent project when I was the sole designer responsible for all of the product, design, and much of the project management. I hope this methodology supplies you with a mental toolkit to prioritize work and approach it at the appropriate level of detail.

Gone are my days of 10 AM paralysis, spending so much time determining what to design that I design nothing. Scanning back through my calendar, I can see my tasks cleanly divided into the three lenses, and as I sit down to compose my thoughts, I realize I would have been lost without them.

error: Content is protected !!