The design of software user interfaces requires five different ways of looking at things. Some very amazing people manage to do all five (for instance, Bruce “Tog” Tognazzini, former User Interface Evangelist at Apple). For the rest of us, we need to identify which parts of software design fit our minds and find people with complementary skills.
—
The «Need» lens
A brainstorming expert, easily comes up with new feature ideas, some of which might actually be feasible. Might be a creative genius or simply someone who listens to existing users and potential buyers a lot. This man or woman is the starting point of any software design endeavor: they hold a complete high-level vision of what needs to be achieved, though they do not know the details of how it will be achieved. Without this lens, everyone else will just run around in circles.
The «Architecture» lens
Deeply familiar with the structure of the software, this person can instantly determine the consequences of a butterfly flapping their winds in form A over the thunderstorm in screen B. The architect is your sole line of defense against painting yourself in a corner. Without this lens, teams discover two months into development that they have to display the user’s birthday even though the program never asks for it.
The «Process» lens
Knowledgeable about the day-to-day design of user interfaces, this team member should fill in the details of how the high-level objectives should be achieved: what does the user see? What can they click? What must they fill in or select? What happens when they do thi–oops. A strong ability to identify corner cases is essential so that no design holes are left unchecked. Without this lens, the team can create a list of friends, but they will not make its columns sortable and they will not handle empty lists gracefully.
The «Implementation» lens
Experienced in the art of software development, this veteran sorts suggestions into impossible, hard and easy based on how hard it is to implement them, then proposes cheaper alternatives based on existing technologies and components. This should be someone actively involved in the actual implementation, skilled in both technical problem-solving and human-to-human communication. Without this lens, everyone else will think up beautiful designs that take years to complete.
The «Simplification» lens
A perpetually unhappy, lazy person, always eager to complain about how long it takes to perform a task or how difficult it is to understand a certain concept. When everyone else just takes the current design for granted, this team member is not blind to its flaws, and points them out until the others listen. This is the mind behind Amazon’s «one-click checkout» and GMail replacing «Are you sure you want to delete this» with «Deleted. Click here to cancel» Without this lens, the software will work, but will be difficult to manipulate and understand.
—
What about me? I’m excellent when it comes to Architecture and Implementation (due to my technical background) and have an acceptable aptitude for Process and Simplification. I’m downright mediocre when it comes to Need (I guess you could summarize this as AI/PS/N to imitate the Briggs-Myers personality type system). So, I tend to seek out people who are adept at identifying needs and good at imagining processes and simplifying designs.
An interesting observation here is that four of the five lenses don’t require any implementation experience at all, and from my experience, implementation skills are seldom accompanied by an aptitude for Need and Simplification. Could a software design career be good for you?
For those of you who are doing software design: what are your lenses? Do you see anything missing? Would you like to have a self-evaluation poll to help you identify your aptitude with these five lenses?
Hi. I'm Victor Nicollet,
I think I’m the opposite of you. I have a technical background, but that stuff has never really been my strength. I think I make up for my architecture and implementation deficiencies mostly with simplification and process. I’d say I’m average at identifying need.
I’ve worked at companies where I’d be doing most of the design (process & simplification) and someone else implemented my designs. This worked well in many ways, but the problem I ran into is that the implementer and designer have fundamentally different goals. As you said, someone looking through the implementation lens is focused on finding easy solutions which often leads to making UI compromises. The designer generally wants the software to work in an exact way and compromising that vision is what leads to mediocre design (think Microsoft). Any thoughts on this? How can the two sides reconcile their differences?
Great post. It’s got me thinking about what I need to focus on to improve my software design abilities, and who I need to hire when the time comes.
I believe the implementer (the “lead developer”) needs to wear a different hat while in design meetings. Outside of those meetings, he has a goal of implementing the design as quickly and cheaply as possible. In those meetings, his only goal is to accurately estimate the cost of implementing every proposal that flies around. Let the actual stakeholder decide whether a given feature or design blueprint is worth the time that it takes to implement. If your project does not have a single stakeholder that makes all those hard decisions, you need to find/elect one quickly or hope that you don’t run into a team civil wars.
Nice article! I recognize all these traits as something to look for from what one may call software designer (instead of lead, analyst, architect or manager).
Just a nitpick, you should have named that article “the five senses of the software designer”