The interactions we design separate great experiences from mediocre ones, but in a compartmentalised team, ownership of design details crucial to the experience have a tendency to fall through the cracks between which team member owns which part of the design process.
I call these gaps in the experience ‘neglected design.’ They are the interactions in a design process that aren’t intentional, they’re slapdash and ill-thought out, and often result in frustration for the people that have to actually use them.
These are the moments when the interface makes you feel stupid because no one thought of writing human readable microcopy, when the sign-up form demands strong passwords but doesn’t tell you what the rules are, the website you view on a phone that you can only navigate by pinching, zooming and squinting your eyes to read the tiny type. These are just some of many examples of neglected design impacting our experience.
Neglected design often strikes at the most inconvenient times, it erodes our confidence, and leaves us feeling enfeebled as we blame ourselves for something that is actually the fault of the team that created it.
In the details
As John Medina, the author of Brain rules, states: we’re hardwired to link emotional experiences to memory. Our brains let off dopamine to reward us like Post-it notes when we do something enjoyable.
The negative, neglected interactions are just as likely to be remembered, as Daniel Kahneman’s peak-end rule has shown us we actually remember the experience by their peaks and by their troughs. We can be forgiving if there is enough reason to be, but if the most important interactions give us pain and frustration we may find they’re avoided in the future.
We can improve these experiences by designing for each microinteraction to be helpful and useful, and by paying close attention to the emotional states when people are interacting.
Neglected microinteractions are caused by a number of things: misguided assumptions as to how people will use what we create, lack of research because we think we know our audience, legacy and ‘best practices’, the integration, and the default option in a framework or CMS.
The people that use what we create don’t care whose fault it is if the experience sucks, they just care that the experience sucks.
There are a number of parts of any web product that fall imbetween clearly defined roles – web animation, the validation of forms and error messaging, naming things, scalable vector graphics, performance, the choice of architecture, the system or CMS – these are all things that have a clear impact on the experience of the people using our products, but it’s not abundantly clear who takes charge of these smaller parts. These details essentially exist in a domain with no ownership.
When we enter this area of discussion about cross-disciplinary thinking, it can be difficult to get past the initial territorial disputes if we don’t think about our common interests. As designers and developers we’re part of a whole that is fostering behaviours – our job might be to try and help people sign up to something beneficial, to aid them in purchasing decisions, or to inform them of important information. We need to have some level of understanding of what drives and motivates people to improve upon our ability to do these things.
“When you look at design as a process and not an artifact, everyone on your team becomes a designer.”
The myth of multi-disciplines
The immediate knee–jerk reaction to cross-disciplinary thinking is that we couldn’t possibly be good at anything if we’re good at many things, this is among many arguments that people make against being cross–disciplinary.
The first argument is related to how we look at generalisation and specialisation. As Jared Spool said in a recent Event Apart talk – we can think of our skill separations as how doctors work. A Doctor spends some time being a generalist before they specalise, it means that a specialist can still perform almost any job relatively well, while a compartmentalist is a person that can only perform one job well.
Our roles are multifacted
The second argument is that you somehow need to be an absolute master of everything. The idea probably comes from how people have defined &ldsquo;the unicorn,’ in the past, equal parts designer and developer. The reality is that even a role like a designer, or a developer is a multifaceted one.
Some designers are great at illustration, at logo design, at interface design, some designers are great at designing microinteractions.
When you take things down to a modular level we’re building a set of smaller components that do specific jobs. What’s actually important to learn is the nearest design, copywriting, or psychology concept to what makes your modules be more successful.
Losing the dream
The third argument is that by being multi-disciplinary we lose ‘blue sky thinking.’ Design is problem solving to a set of constraints, you can either rely on a developer’s word to tell you what those constraints are, or you can learn the limitations yourself - perhaps you will learn that there’s an approach they didn’t think of.
As a developer armed with design knowledge, you might learn the intention that a designer is trying to create – you know what they want will take days, but because you understand design you can suggest good alternatives that might be created in an hour. This is how design and development can inform a project together.
The problem with ‘designers need to code’
“Designers need to code,” is a statement that I’ve heard from many developers who haven’t taken the time to learn to design. I think it’s a little misguided, a more accurate statement should be ‘Everyone should learn to create,’ learn the basics, learn the reasons and the rationale and be able to critically think through design and development decisions.
By skilling up in the basics that relate to the work that we do we can avoid these unintentional moments of neglected design, we can share the ownership and make sure nothing falls through the cracks.
We can avoid frustrating the people that use our creations – because they don’t care about blame, they just care if it works well or if it doesn’t.
When we invest our time and money into better knowledge, we’ll make better communicators who are capable of creating greater experiences for people to enjoy and remember.