Needs & lacks
Most designers would agree that need-finding is an important thing to do. We seek to better understand our users so we can make better software for them.
Itâs a central part of the design process. Hereâs an excerpt describing what Dropbox Design team gets up to:
Combining research, data, and thoughtful critique, we're discovering needs and solving fundamental problems that impact work and life for millions of people around the world.
And thereâs no shortage of âhowâ material out there ranging from good to questionable, so I wonât spend too much on that.
Yet in my experience, need-finding is a mysterious, slippery thing.
Why?
It doesnât really have a definition.
Ask 100 product designers what a âneedâ is and youâll get 100 different answers, or 100 non-replies.
The Facebook approach to building software describes a need as a âpeople problemâ.
From Julie Zhuo:
A people problem is a need, issue or opportunity articulated as someone on the street might understand it. Good people problems identify what people want to do in their daily lives and pinpoint what is broken or unsatisfying about their current solutions.
eg. âPeople are bored and uncomfortable on airplanes.âÂ
Charlie Sutton, another Facebook design leader, adds to the definition:
A people problem is human, simple and straightforward.
eg. âI know how to save things on Facebook, but donât know how to get back to it.â
Airbnb designer Lenny Rachitsky, has a slightly more loose explanation that includes the business:Â
A strong problem statement should reference a âneedâ that is not being fulfilled. Try to focus this around a user need, but can also be a business need if necessary.
eg. âAirbnb hosts are feeling frustrated because they want to improve, but are finding it difficult to figure out how.â
And a good hypothesis will usually speak to a user need.
Hereâs an example of a hypothesis from the Patreon product team:
We believe that Patreon creators are highly motivated to use our platform, but experience writersâ block when building their pages because when the customer success team helps a creator launch, most of the time is spent helping them find relevant examples.
And finally, hereâs something from the archives, an obscure paper by Rolf A Faste.
We speak of needs as though they exist in some real or physical way. We say âI need a car,â or âI need a house.â In actual fact, cars and houses are not needs in themselves, they are but one way to meet certain needs such as mobility or shelter. The need itself is a perceived lack, something that is missing. Needfinding is thus a paradoxical activityâwhat is sought is a circumstance where something is missing. In order to find and articulate a need, this missing thing must be seen and recognized by someone.
The products we design donât always support the needs of users.
Youâd think by now weâd have a simple clarified way of building features that are designed with the intention of directly meeting the needs of our users. We donât.
Weâre definitely getting better at it. Before my time, in waterfall world, a large requirements doc would be plonked on the desk of an engineer. Filled with functionality but with no rationale of why it should exist.
Weâre getting better. Design thinking, love it or hate it, aims to put much more focus on the end-user before anything is even typed up into a doc.
But can we do better?
Conceptual design: A software design approachÂ
Daniel Jackson, a MIT professor, thinks we should build software incrementally in âconceptsâ that all have a purpose and are designed around the needs of users.
An example: Think about âtrashâ on a mac. Itâs a concept. The purpose? Allow the undo of deletions.
Imagine if every time you deleted something it was immediately gone forever? That would suck. It solves a problem for a user and makes the software a bit more friendly.
A more 2019 example might be the âholdâ function on a Jump bike. âHoldâ is a feature, a concept, a solution. And itâs connected to the need of a casual cyclist. A lack.
Users of an earlier iteration of the app may have said something like âI wish i didnât have to restart my ride every-time I stoppedâ. Or, I locked it and I came back 5 minutes later and someone else had reserved it! Or maybe Uber noticed people were leaving their bikes unlocked and running so they could stop by multiple locations rather than just riding from A to B.
Designers perceived a lack, something a bit âbroken and unsatisfyingâ and sought to solve it with a concept called âHold Bikeâ.
I donât think concepts solves the inherent muddiness of solving user problems but I love two things about it. 1. Itâs simple and easy to learn. 2. It maps directly to how we build software. Itâs not to different than a requirement, a bit of functionality or something that could be built in 2 weeks.
To design learnable, effective and tolerant systems, designers should be thinking about concepts (and their related purposes).












