Writing an interface

The language of interfaces can pose some unique challenges. Usability problems usually fall into two categories; either it’s not clear how to do something, or something is too cumbersome to do.

The latter is fixed by a better understanding of what the key tasks are, and the former is usually resolved by adding clarity. Often the best way to do this is through the writing of the interface.

Wireframing is a low fidelity way of exploring ideas; it’s not a good time to obsess over the words. There is a time and place for obsessing over the writing in an interface, and that’s what this presentation was about.

Writing Microcopy

Writing an interface has similar traits with writing anything else. Some pieces are obvious, some flow naturally with the application, and some you’ll read back and wonder who was dropping acid in your coffee. It’s convenient to break down a design into components like visual, layout, typography, and content; but this division often ignores the inter-dependencies. If your visual designer only leaves you 10 characters of space to explain a button, the content, and therefore the usability, can suffer because of it.

That said when I review all the copy/microcopy/labels/whatever in an application there is always low hanging fruit. Quick wins that everyone will appreciate. I usually work with the designer or app owner to re-write pieces. If I have little domain knowledge I just ask a lot of questions.

Questioning your copy

1. Who is it for? Any user, new users only, old users, free users? New users benefit from more precise instruction. Telling a new sign up to change their notifications “in preferences” isn’t clear; most likely they don’t know where preferences is or what icon represents it.
2. When they do see this message? Does this appear as a reaction to a user action, or is it something that is processed behind the scenes (e.g. charging a credit card). Does it appear immediately? Does the user expect it?
3. What do they need to know? Self explanatory.
4. What must they do now, if anything? Often messages have a next step attached; something you’d like the user to do or decide. This should be the logical conclusion of the message.
5. How is this communicated? On screen, pop-up, by email, iOS notification, SMS? Everything that’s good for something is bad for something else.
6. What tone does this app speak in? This is driven by the brand. Some apps are cute. Some are fun. Some are exact and precise. OKCupid can be flirty, and Mailchimp can be fun. A investment website should probably be neither. Productivity apps are best kept clear and precise. The tone of your app is an easy way to stand out, just be sure to stand out for the right reasons.

All that for a string of text?

This may seem like a laborious list to go through for each label and message, and of course many will done in microseconds, e.g. Cancel, Edit, Save, etc. The above questions are for the labels and messages that aren’t coming to you easily.

Slides

Here are the slides from a talk I gave on this topic to the Content Strategy Forum.