Neglected design

The interactions we design can 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.

These are the moments when the design makes you feel stupid because no one thought to write copy for humans, the sign-up form demanding strong passwords with no clear feedback as to what they want, the website you view on a phone that you can only navigate by pinching and zooming and squinting your eyes to read the tiny type, the drop down menu which activates on hover when are viewing the site on your touch screen tablet, and the changing state of an application that jolts into view with no hinting as to what just happened.

Apple IOS 7 Keyboard
Neglected design: Apple's IOS7 Keyboard lacks clear feedback on the shift key to communicate to you whether it is on or off.

Why detail matters

We’re hardwired to link emotional experiences to memory. Negative interactions like these are the most likely to be remembered, if your website or product is frustrating people, it might be avoided next time in favour of a better experience.

We can improve upon these experiences by designing each microinteraction to be as helpful and useful to the people that use them, and pay attention to their emotional states at those moments.

Mailchimp rewards you with a high five when you send a campaign
Effective emotional design: Mailchimp picks a moment of anxiety to reward you with a high five.
Slack recognizes that typing credentials on a small screen is difficult
Slack recognizes that it's difficult to to type in your login credentials on a small screen device, instead they avoid the frustration by giving you an easy way to login.

Who owns the details

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. It's easy to blame the designer for missing these details, but often the designer is simply unaware of the detail, quirk, or interaction existing in the first place. Similarly, the devleoper might not understand which details are important when integrating the design. Some features, such as validation, are added into the design process at the end by the developer. Some are added as part of the system in which the application or website live. These details exist in a domain with no ownership.

Drupal 7s admin interface
The interactions in an admin interface are key to any CMS, Drupal 7's are incredibly difficult to learn for new users because they go for options over simplicty.
Healthcare.gov is an example of design by site architecture, the site wouldn't work for many users
Healthcare.gov struggled when it was initially launched because the chosen architecture wasn't capable of handling the load and requirements of the people using it.

Distributed knowledge

We are trying to foster behaviours with our designed interactions, we need to have an understanding of what drives those behaviours and begin understanding areas of the process outside of our specialisations. Everyone should be able to write some copy, evaluate what makes a design successful or pick out potential pain points before they happen. Designing interactions effectively is a task that requires a multi-disciplinary approach across research, copywriting, psychology, design, and development.

“When you look at design as a process and not an artifact, everyone on your team becomes a designer.”
- Cap Watkins

Education is key to better interaction thinking, if the team learns the fundamentals, details are less likely to be missed because there are no longer any skill gaps for the key moments to fall through.

Distributed knowledge like this has other added benefits: positioning us better for future technologies, interaction methods and features. The first people to learn of, and try future technologies in a team are usually the developers, but those who add vision to the technologies are (usually) designers. The first people to explore Internet of Things hardware, experimental device inputs, and the first to explore CSS features like Shape and Flexbox are developers.

Common ground, shared language

Small decisions in our design process can also have consequences which lead to large amounts of work for very little gain, working collaboratively and being able to discuss and understand the intention of those decisions means we can create alternative executions which are just as effective.

Better experiences

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 ownsership 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.