In the 1967 Peter Cook/Dudley Moore comedy “Bedazzled,” the embodiments of the legendary 7 deadly sins played minor (and sometimes not so minor) roles in the ongoing temptations that the Devil (Cook) manifests upon the protagonist Stanley (Moore) in his (hilarious) efforts to wrest Stanley’s soul from him for eternity. Particularly memorable to my then-young eyes was the lovely Raquel Welch as Lust.
Just as the 7 deadly sins visited troubles upon Stanley, similar temptations sometimes overwhelm the best intentions of Designers, Marketing and Product Managers, and Company Founders alike.
Let’s start with Raquel’s character: Lust.
Lust: I want my UI to look just like this other fabulous (but inappropriate) UI that just came out.
It’s okay to want nice things. It’s useful to aspire to levels of product refinement and resolution based on exceptional work in the market. But those overcome by this sin can expect to be tormented for letting their desires sway their reason; “Ooh! Shiny!”
Designers and manufacturers of in-vehicle UIs and industrial equipment incorporating touch screens seem particularly susceptible to Lust’s charms. Having seen the UI for some successful touchscreen devices, the desire to replicate it overwhelms budgets and resources. The trouble starts when the full breadth of requirements to achieve it are misunderstood or ignored: cheaper touch technologies replace the responsiveness of capacitive input; interactions that require fine motor skills are placed at arm’s length; and the collection of systems (visual design, input, underlying processor power) is not refined to work cooperatively – it can’t provide the fluid interactions users expect from modern touch OSes. The result is a continuous series of unmet user expectations that lasts the duration of the user’s ownership/use.
Gluttony: Rather than carefully select which use cases we want to address with great experiences and interfaces, let’s just expose every possible setting or feature and let users figure it out.
Everyone loves the all-you-can-pile-on toppings at the frozen yogurt shop. But few of the creations well-meaning yogurt aficionados bring to the pay-what-it-weighs scale can compare to the fine crafting of flavor profiles and textures an accomplished chef can render by curating a small number of high-quality ingredients into a delicious dessert.
The gluttonous UI offers users every possible combination of features, looks, themes, toolbars, and palettes, and leaves the task of finishing the software design as an exercise for the user.
While power users — usually a small but vocal contingent — might love this approach, the other 4 users out of every 5 will pay the price of added cognitive cost, driving dissatisfaction, inability to find or use features, and possibly, abandonment.
Greed: There’s no point in us spending time or money designing the UI. Someone can make it “pretty” at the end. Didn’t we download some icons from the internet? Can’t we just use those?
Succumbing to Greed is different from Sloth (coming up next). While Sloth is a sin of omission, Greed is a sin of commission: an explicit decision is made to “save money” by hiring a designer to “make things pretty at the end”. This approach ignores that “[design is] not just what it looks like and feels like. Design is how it works” (Jobs, 2003). A thousand decisions get made on the way to a product. Reserving only the last 10% for someone trained as a designer rarely succeeds in reducing development costs or creating products that users love.
Sloth: I’ll just ignore it until the end, or just ignore it completely.
The popularity of the app economy has Sloth on the wane as one of the 7 deadly UI sins as more and more companies are founded with designers at C-Level or Founding positions. The ruthless app marketplace has demonstrated that design is no longer a luxury; it is a critical component in the product development process.
Despite that, the enterprise software landscape remains well populated with applications and software tools for which design was either never considered — an omission — or only considered at a point too late to affect the interface’s trajectory. The nature of software development — continuous product iteration — offers the opportunity for redemption from this particular sin. “We didn’t have a plan before, but we can create a product and feature roadmap (design!) today for the future.” It just requires the sinner to recognize and accept the opportunity. Failing to do so dooms your UI to ill-considered features grouped confusingly for the (probably short) life of your product.
Wrath: I can’t believe our users can’t figure out how to accomplish [some use case] and keep haranguing me about it in our support forums and app reviews! There are 6 [mutually exclusive] ways to accomplish that goal! I give up. I’m removing the feature.
User punishment can take a number of forms, with spitefully removing features or adding a half dozen redundant — but exclusive to each other — ways to accomplish the same goal among them. While this is similar to the here’s-the-kitchen-sink-of-features-you-figure-it-out approach delivered out of benevolence as gluttony, make no mistake: the user-as-enemy perception is the difference that qualifies this sin as Wrath. When users are incapable of divining the use of our products, that’s our fault, not theirs. It should be obvious that Wrath is not the hallmark of a healthy user/product designer/program manager relationship.
Envy: That interaction is so charming and delightful in that tablet app. I MUST HAVE THE SAME THING IN MY DESKTOP SOFTWARE.
Pushing the boundaries of what’s acceptable on a software platform drives innovation. Sometimes, exceptions to the rules become the rules. But as with art, a keen understanding of the rules is required before a designer can identify where they can be bent or even broken – pushing boundaries is different from adopting interactions inappropriate for a given platform. Consider that tablets have existed for more than a decade, but only after an OS was designed that recognized the dramatic differences in input modalities and input bandwidth between a tablet (with or without a stylus) and a desktop PC — with a larger screen, keyboard, and pointing device — did they become the dominant device sold. Recently we’ve even seen some designers apply interactions appropriate to a tablet environment to desktop applications, but the results are mixed at best.
Pride: Our UI engineer can design the UI as he’s coding it. He’s pretty good at it. So we don’t really need a designer.
This is a variant of sloth and greed, but for a different motivation, and rarely do designers (who are not coders) attempt the opposite. While there are examples of where this works, finding the two-sport star capable of dispatching both tasks well is rare. Proceed with caution.
In the end, these transgressions are mostly about moderation. It’s OK to want to ship nice shiny products (in fact, it’s pretty much required these days). It’s OK to want to provide your users with a range of features. But as with their namesakes, while most of these are acceptable in judicious moderation, they go wrong when taken to extremes (Wrath being the obvious exception; I can’t think of a time when it’s OK to punish users).
How many of these sins are you guilty of? We’re ready to help the penitent.
Featured image by highwaycharlie | CC BY-ND 2.0