Dark patterns are when people design interfaces intending to deceive or trick. Sadly we are all familiar with these. They're everywhere. 

It could be the free trial that unexpectedly led to a subscription or the subscription that was easy to sign up for but had to be canceled by mailing in a letter. Or it could be an outward attempt at giving control over privacy but with options so confusing as to do the opposite. Perhaps you tried to adjust cookie preferences on a news website but could only find a button to 'Accept all' after editing your preferences—grrrr! Tricking people like this into sharing more information than intended has come to be known as Privacy Zuckering.

Remember popups that could only be closed once you found a tiny 'x' that moved around the screen?

I recently wanted to pause a subscription only to be told it would invalidate all the accumulated unused credits I'd paid for (I'm still paying). The Pudding published a great analysis of unsubscribing from online services. At times this may be unintentional—there's naturally less incentive to work on great account closing and unsubscribe experiences than on signing up.

The example in the sketch was a real one I experienced (I wish I'd grabbed a screenshot) from an airline website where the designers buried the option not to buy insurance within the country select list.

And they're not just online. Sneaky casinos employ design in the physical world for their gain, such as removing references to time passing, such as clocks or windows, using mazelike navigation and the continual winning sounds of jingling coins. 

"Dark patterns" was coined by Harry Brignull and documented at the Deceptive patterns site and now a book.

Dark patterns

When writing for the web every word counts. We scan pages, instructions, and emails, sometimes skipping reading completely. So it's key to make sure that every word is doing a job. Over the years I find there are words that I routinely trim from web copy to save space and keep focus while preserving intent. While context always matters and these can't be cut everywhere, here are a handy few that regularly get the cut from web copy:

Obviously, clearly, of course and the like — if it's obvious then don't write it, if it's not, then it's not relevant. If it's obvious to you and not to me then no need to make me feel stupid reading it

Note, please note, note that, notice — we're noting it by writing it so trim the noise by leaving out reminders for readers to note things. If you really want someone to notice you can use the extra space from removing it by making it bigger or bolder

That — can often be trimmed without changing the meaning of a sentence

Exact — very often makes no difference to a sentence

Famous — if it's famous then maybe I've heard of it. If I haven't, then perhaps it's not so famous

Current — if someone asks for my age or job then it's normal to assume they're not asking for what it used to be

Successfully — it's always nice to trim a long word that doesn't add a lot

Have — like 'that', it can often be removed without changing the meaning of a sentence

All, total — when I take these out I often find it's the default assumption anyway

Interestingly, surprisingly and the like — it may be interesting or surprising to you, but I think it's polite, and briefer, to let the reader decide if it's interesting or surprising for them

If you're writing for the web, try removing some and see if it still works.

Micro-editing redundant words

Often, the form of the data is obvious enough for what it is that you might consider simplifying by removing the label.

Let your data speak for itself.

I find myself linking to this article about why your links should never say click here for links on the web that I thought I should just get it down for easy reference. The solution, generally, is to rewrite your sentence. For more about writing for the web, click here. Only joking, check out more tips about writing for the web.

Also see: Omit unnecessary words, use styling instead of colons, cognitive overhead and the best writing is rewriting. 

Rewrite to avoid click here

A shift in the way we develop for digital devices. The mantra used to be ‘graceful degradation’ - design for what you expect people to use, then let your application gracefully degrade for older browsers, and smaller screens. Generally speaking the richest application, and the first to design for, was on the desktop.

A more recent approach is mobile first. Start with core content, design for the smallest screens and least capable browsers, then progressively enhance the experience onto larger more capable devices, browsers and screens. My intro from Mobile First by Luke Wroblewski.

Progressive enhancement

Metaphors for interface design from Rachel Hinman via Mobile First.

Mobile is snorkelling. Desktop is diving

Sam Moreau, User Experience Director at Microsoft. Just one small example.

Had a few questions about this so thought I’d add another simple example. Imagine you want to change your phone number on a service. Rather than display the phone number and have an option in a menu to edit and then a separate edit screen, the phone number itself can be the route to editing. You simply display the current number - clean, no junk. Mousing over it or clicking on it allows you to edit it directly. You remove the need for additional menus, text, instructions, and chrome. The content itself becomes the interface.

The content is the interface

I still find somewhat remarkable the complexity in a simple button on the web. These are just 6 common states that may each have their own appearance and behaviour.

Common button states

Classic rule of thumb from Jakob Nielsen. Probably the most useful corollary is if you can afford 15 tests, tests 5 users 3 times each and iterate the design in between.

5 user tests finds 85% problems

Two and a half words of wisdom from Steve Krug. Still worth reading Don’t Make Me Think.

Omit unnecessary words

Remove submit buttons on clicking to avoid double submissions

On transitions should be fast (to feel zippy). Out transitions can be slow

Keep essential information out of tooltips

Sketchplanations tagged with ux