“The words we write may be tiny at times, but have a big impact and convey a lot.”—Roxanna Aliaga, UX Writing Manager at Dropbox
Words are important, but as obvious as this statement might seem, this fact hasn’t always been evident in the design of product user interfaces. Twenty years ago, the pop-up error messages of the Windows operating system were full of jargon, and the user interface was so unattractive that people would sometimes just click an Accept or Exit button without even reading the message text.
Today’s writers, marketers, and designers know that a single word in combination with the right visual design can make the difference between a user who engages with your brand and a user who never comes back. UX writing is about emotion, accuracy, and strategy. Let’s explore this fascinating, new field. Read More
In this column, instead of talking about one of my usual topics—tactics to avoid errors—I’ll discuss how to work within constraints and pragmatically address real-world issues. During the software-development process, your team may ask you to design an error message. Annoying edge cases all too often pop up—usually too late in the process to fix the issue in any other way.
For starters, I never write what I’d call error messages. Admittedly, I occasionally use that term—in the same way I might use words such as sitemap—just at the beginning of a conversation to orient everyone to my process. Just as I did in the title of this column. But I then switch to a more meaningful term and get everyone to talk about exception messages. Read More
Since I wrote my article “Mobile Inline Form Validation” for UXmatters back in 2012, I have very rarely used any of those patterns in my own work. Recently, when I created a pattern library for mobile applications for a big, multinational, corporate client, I didn’t include any of those tips. Since the publication of that article, I have identified and begun to follow a few principles that are I hope more user centric.
Don’t See Users As the Source of Errors
If you design systems, you are familiar with constraints. For example, it is hard to add new fields to a database; mobile networks sometimes provide poor connectivity or have slow performance or high latency. Typically, system design takes such constraints—and, of course, costs—into account in determining what a team can build. Read More