Mind the gap
To design is to bring about a desired state of affairs.
- Edward de Bono
When we build software, the delivery process is broken into two chunks. Designers focus on making something learnable, effective and tolerant, and then share their solutions with developers.
Meanwhile, developers are responsible for ensuring the implementation is maintainable, correct and fast, among many other things. That’s how stuff gets made.
But there’s a gap in the middle. The designs have to be understood, or they’re worthless. Whether their audience is technical or not, effective communication becomes a critically important step in the design process.
To further illustrate the challenge, let’s explore the potential behavior of something in the real world. A train door.
The train arrives at a station, the doors open, passengers can flow freely on or off, the doors close, and the train moves on.
If the purpose of the door is something like ‘allowing passengers to board and exit the train’, what else do we need to know? I’d ask a few questions, including:
What technology does the door have access to? And does the technology enable or restrict certain behaviors?
Since the door will be heavily used on a daily basis, how does it respond based on the fluctuation of the crowd? Does it work differently during rush hour?
How do people physically interact with the door? Do they push it, pull it, or stand aside and wait for it to move? How do they know what to do? Does the door ‘signal’ and give clues about its functionality? Does it reuse a common pattern? Can the door open with other means? By voice, hand gesture, or by scanning a ticket? Is the door accessible?
Consider that a door is frequently opening and closing at every stop. Passengers will observe and quickly learn the behavior. They’ll similarly tire of loud, or attention demanding designs.
Are there different variations of the door, with different behaviors, built for different scenarios? Consider the difference between the emergency exit and the primary access to an airplane. Will they know how to use it? How do passengers know the difference?
What are the states of the door? eg. standby, locked, open, closing, opening, pre-close, disabled etc. What conditions or interactions triggers those states?
In New York City, a closing door on the subway will often snag a bag, or coat in its way. The sensitive edges trigger the doors to reopen and stay open until the obstruction is cleared. This behavior can be helpful, and even save lives. You can imagine the problem if the door maintained pressure on whatever’s trapped. But it also comes at the nontrivial cost of increased ‘dwell’ time at each station for the train.
Do passengers have control or does the train operator? If train doors usually open automatically when the train stops, it’s confusing to encounter doors that need your help. This happened to me recently in Copenhagen. I stared dumbly at the closed door until a local reached past me and pushed a tiny button to open the doors.
In London, passenger control buttons were eventually abandoned because “tube bosses realised that dwell time at stations would be reduced if the doors were opened by the driver, rather than waiting for passengers to press the button.”
Is the status of the doors visible to non passengers, like crew members or train operators? What happens if some railway platforms are too long for the train? Can the driver choose which doors to open to prevent passengers falling into the tracks? Is that status visible to passengers so they don’t miss their stop?
In software, ‘delight’ is used to refer to an extra layer of value built on top of the programs behavior. Consider the sound and satisfying feeling of luxury car door swinging shut. It’s no accident that it signals quality to the driver/owner/customer.
What else could particular behaviors communicate? Do we want the warning sound to be memorable, musical and distinctive?
Exhausted? We’re just getting started!
Where to next?
The biggest difference between software and the real world is data. And that’s a big difference. But in many ways software behavior is not that different. It still has to answer many of the same questions I lobbed at that door. The designer is still figuring out what it can do, in the context of people who use it.
Design really is how it works.
And you still need to effectively communicate that behavior. When communication falters, things get nasty. Quality and velocity both drop. Charlie Deets, a product designer at WhatsApp, suggests three things to help improve designer/developer communication. Learn code, prototype, and write better specs. Unfortunately, an animation or a detailed (but static) red-line document, often struggle to clearly communicate the programs behavior or accurately represent the underlying data.
We have a lot of room to improve. The tools used by video game developers hold some clues as to the possibilities available and the direction we could head as an industry. I can’t predict if that will happen, but I do know Framer isn’t the answer. Neither is Figma or JavaScript or inVision Studio or more Sketch plugins.
We need a simple, smart and robust way to communicate the desired behavior of software.
And that’s an opportunity.
