Menu

Posts tagged “design”

Content Designed to Manipulate Users

Back in 2004 Adam Greenfield wrote down some ethical guidelines for user experience in ubiquitous-computing settings. He starts off as follows:

Principle 1: Default to harmlessness. Ubiquitous systems must default to a mode that ensures their users’ physical, psychic and financial safety.

That might sound a little overly dramatic, but as we’ll soon see, it’s a very important principle for a designer to keep top-of-mind. Adam goes on to say this:

Principle 5. Be deniable. Ubiquitous systems must offer users the ability to opt out, always and at any point. As an absolute ethical imperative, users must be afforded the ability to make their own meaningful decisions regarding their exposure to ubiquitous perception, the types and channels of information such exposure will necessary convey, and the agencies receiving and capable of acting on such conveyance. Critical to this is the ability to simply say “no,” with no penalty other than the inability to make use of whatever benefits the ubiquitous system offers its users.

Now. Think about those principles, and then have a look at the newsletter preferences page for eBucks:

eBucks Newsletter Preferences

The text in the opt-out line reads:

I’m not concerned with my eBucks balance and I don’t think I should be the first to know about all the latest news.

It’s an interesting content approach taken by eBucks, and one I would argue violates both principles I quote above. They are basically making you feel out of touch (“be deniable”) and a little bit stupid (“default to harmlessness”) if you don’t subscribe to their newsletter. Are they also implying that you won’t be able to view your balance if you don’t subscribe? Probably not, but it can be interpreted that way.

Fast forward a few years after Adam’s article, and we now even have a name for this type of tactic. It’s a classic example of persuasion design:

Persuasion design doesn’t share User-Centered Design’s ethical neutrality. Instead, it makes an implicit but undeniable judgment that certain behaviours are preferable to others.

Persuasion design prioritises business goals above those of the user, and its values are irreconcilable with empathy, the central value of User Experience.

This is just one example, but you can see it everywhere. It might seem innocent at first, but it’s such a slippery slope to the evil of dark patterns. We need to consider the implications very carefully before we employ such techniques.

Speaking the web's language

Frank Chimero on why designers should learn to code:

Design decisions are not only affected by the characteristics of the content being designed, but also the qualities of the format. The best way to understand the characteristics of the web is to speak its language.

Good design and good markup provide structure to content. Good markup is a fundamental part of good design: beautiful on the inside, beautiful on the outside. HTML and CSS give another venue to provide structure to content in the native language of the web, and learning these guides decisions by surfacing the affordances of the medium. Design decisions are affected by both the content and the format, like how a sculptor would make different decisions if she were working with clay rather than marble.

Spot on. The whole post is worth a read, and Frank gives some good suggestions for resources to help designers get started on coding.

UI Conventions and Inverted Scrolling in Mac OS X Lion

My favorite sentence from John Siracusa’s epic review of Mac OS X Lion is this one:

Apple appears tired of dragging people kicking and screaming into the future; with Lion, it has simply decided to leave without us.

And nowhere in Lion is this more apparent than what appears to be everyone’s least favorite feature: inverted scrolling on the trackpad. As I’m sure you know, what this means is that scrolling now mirrors how it works on iOS devices: you essentially drag the content up and down the screen, as opposed to moving the viewport of the application like we’re used to.

Natural scrolling in Mac OS X Lion

I love this change - it took me about 5 minutes to get used to it. But I appear to be in the minority with this opinion. It sounds like the first thing most people do once Lion is installed is head over to Settings and change it back to the old way of scrolling. So I’d like to step back a little and use this change to talk about UI conventions and when it’s ok to change them. To do that, let’s first look at what we know about Apple’s direction for their operation systems.

Data Is The Future

We got our first glimpse into Apple’s future at WWDC, where John Gruber summed up the keynote as follows:

Googl’s frame is the browser window. Appl’s frame is the screen. That’s what w’ll remember about today’s keynote ten years from now.

Robert X. Cringely touched on the implications of this in an article about Facebook where he says this:

The trend is clear from “the computer is the computer” through “the network is the computer” to what’s next, which I believe is “the data is the computer.”

The point is this. Up to now the metaphor we’ve had about computers is that data = files, and we view this data through windows (with a small “w”). We then manipulate these windows around to get things done. With the introduction of iOS, Apple noticed that the metaphor is not only unnecessary, it’s also not the most effective way to do things.

Instead, Apple wants us to remove the current abstraction from our data (the file system and the “window”), and instead focus on and interact with the data itself. Our data no longer has to be served to us through a middleman - we can go straight to the source. In this context, inverting scrolling behavior makes total sense. Why would you move a window around to see data that sits somewhere behind it, when you can manipulate that data directly? If the data is the computer, scrolling down should move your words down the page, not up.

Inverted scrolling is only one piece of the puzzle. Full-screen mode, disappearing scroll bars, auto-save - these are all new features in Lion that build on this fundamental shift away from file-based computing to data-based computing[1].

But there is a problem with this shift, as we’ve seen from the outcry. People are used to doing things a certain way, and you can’t just go ahead and change that without asking permission. So how do you deal with a change like this?

Floppy Disks And UI Conventions

Another example of this kind of conundrum is the trusted old “save” icon - the floppy disk. My 2-year old daughter will probably never see a floppy disk in her entire life, yet she will learn that the floppy disk icon = save action. Some have tried to change this - recently David Friedman proposed a baseball home plate as replacement icon.

But getting every software developer (and user) in the world to adopt a new standard like this seems nearly impossible. So, we’re stuck with the floppy disk for now[2], even though it is an outdated metaphor, similar to how scrolling currently works.

So this is where we need to go back to the theory. In essence, reversing scrolling behavior lines up with one of the fundamental heuristics of UI design: there has to be a match between the system and the real world:

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

There is a tension here. Users are familiar with the current concept of scrolling. Yet, I’ve tried to argue above that the new way is actually more natural and logical. Apple is essentially caught in the middle of this UI heuristic, and they had to make a choice. So the question becomes, when is it ok to change what’s familiar to something that’s different but more natural and logical?

You’ve Got To Leave It Behind

The answer is that you make such a change when you believe it’s part of a much bigger trend in computing, and you’re willing to take the negative backlash because you know you’re doing it for the greater good. Ok, stop rolling your eyes. Yes, I’ve been accused of drinking the Apple Kool-Aid just a little bit too much lately. But hear me out, and re-read that Seracusa quote in the beginning of this post.

Apple is undeniable moving iOS and Mac OS X closer to each other. And in their future, direct manipulation of the data (primarily through touch) is at the center of a larger computing shift first introduced by the iPad. So they are making this tough call now, saying, “this is where we’re going, don’t get left behind.”

In short, I implore you to take John Gruber’s advice on this:

My number one Lion tip: No matter how wrong it feels, stick with the new trackpad scrolling direction. Give it a week.

Six months from now I think we’ll look back at Lion and iOS 5 as the operating systems that ushered us into the era of the data as the computer. And we’ll be better for it.


  1. Apps like Notational Velocity have been going this route for a while, where the file system is completely hidden. You don’t interact with it at all, unless you really want to.↩
  2. At least until all developers follow Apple and Google Docs (to a certain extent) and replace save icons with auto-save options.↩

Hierarchy and Aesthetics: Separating Science from Art in Visual Design

In this post I argue that we need to communicate the differences between the science and art of Visual Design better to help change the common perception by stakeholders and clients that user experience is purely subjective.

One of the most difficult aspects of visual design is finding the right science:art ratio to accomplish user goals. I’ve always subscribed to what Tim van Damme calls the mathematics of design. You start with the science:

If art is about talking and expressing yourself, interface design is about listening and disappearing into the background. You listen to the content and its context, and take it from there, one step at a time. Don’t worry about the looks, just start with the variables. 1 + 1 + 1 + ”¦ Baby steps, over and over again until what you have on your screen feels right.

And then you mix in art where appropriate:

But sometimes, even 1 + 1 is too much to handle, and you need to clear your head. This is where art comes into play, in the broadest meaning of the word: Paintings, illustrations, architecture, human beings, even nature is art. They won’t help you decide whether you should draw a 1 or 1.5 pixel highlight, but allow you to take a step back and just decide on what’s more suitable or pick one and move on.

Of course, this is not a serial process. Great designers are able to design within that delicate balance between science and art, and find the right ratio as they’re doing it. And even though it’s not easy, I do feel that most designers inherently get this - that visual design is science and art combined in different levels based on the needs of the user and the application.

What’s even harder is explaining this to stakeholders and clients in a convincing way. Over the past week I’ve seen so many comments about how “UX is subjective” and “standards always change” that it got me thinking about a possible solution to this problem. I haven’t figured it out, but I’d like to write down some initial thoughts for discussion.

The problem with Visual Design

I think as a UX community we’ve done a good job of splitting out the different elements of UX Design. Stakeholders and clients are slowly starting to understand the difference between Information Architecture, Content Strategy, Interaction Design, etc. And most people also now understand that those functions are not just gut feel or whatever is the trend of the day. We’ve done a decent job of showing the evidence behind the decisions we make - thanks in large part to the results of user experience research methods like ethnography and usability studies.

But Visual Design is the odd one out in this equation. It walks the line between science and art so tightly that most stakeholders and clients only see the art part. So they look at a design, make a gut call, and think that it’s all just whatever style the designer fancied on that particular day. Sure, some of it is our own fault, and many designs don’t have enough science at all. As Zeldman pointed out:

When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name ”” at least, in some circles. Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

We have to find a better way forward.

Breaking down the elements of Visual Design

So how do we fix this? One way is to provide a much clearer distinction between the different aspects of visual design. I’m not saying we should split the job title into two functions, I’m saying we should be more explicit about the goals and outcomes of visual design. And it needs to be simple, so it can’t be too detailed. I’m not 100% sure how to do that yet, but here is one suggestion:

  • Hierarchy Design could refer to decisions made during the design process that sets the appropriate visual hierarchy based on the scientific principles of visual perception (such as contrast, grouping, balance, symmetry, etc.). See Designing for the Mind as an example.
  • Aesthetic Design could refer to decisions made during the design process to help the design fit the brand promise and elicit an appropriate emotional response (such as choice of color, typography, button styling, etc.). See In Defense of Eye Candy for more.

Now, as I already mentioned, there is a lot of overlap between these activities, and you can’t have one kind of visual design without the other. But there has to be a way for us to talk to our stakeholders and clients about the visual layer of design that is not based on style preference but on “hardcore usability” as Zeldman puts it.

As we continue to grow and define the different elements of user experience I believe that Visual Design has the most baggage to overcome simply because of the history of web design and its initial focus on what’s pretty vs. what works. What works is not subjective, and we need to communicate that effectively to our stakeholders and clients. It’s not their fault for not “getting it”, it’s our fault for not explaining it properly. Let’s change that.

The problem with Flash and Ster Kinekor's new web site

South African movie site Ster Kinekor just relaunched their web site to much fanfare. Much of the discussion I’ve seen on Twitter about the new site is about their decision to remain completely reliant on Flash. I agree with all the technology arguments against Flash, but I want to take a slightly different approach here and talk about Flash as an enabler of bad user experience.

You see, Flash is like the guy who keeps giving your alcoholic uncle a drink while the rest of the family is trying so hard to help him get sober. Every time he gets close to quitting he gets “one more drink” from somewhere and falls back into bad habits. And this is what Flash is to user experience.

Every time you might get close to following standard UI conventions or have a simple flow, Flash comes in to whisper sweet animatic nothings in your ear… “Just one more flyout,” it says. “Just one more hover state - come on, everybody’s doing it.” Designing a boring old button? “No man,” says Flash, “we can make this thing move and light up with Flash, wouldn’t that be cool?”

And before you know it, you have this:

In my view, most of the user experience issues with the old Ster Kinekor site have not been addressed in the redesign. For example:

  • There is no visual hierarchy on the site. Everything is important, so nothing is important. I just don’t know where I’m supposed to click.
  • Animations are intrusive and adds to the confusion.
  • Standard UI conventions are ignored. Buttons don’t look like buttons, links don’t look like links (links are grey on the site…).
  • Forms are non-standard and not easy to fill out. For example, the checkout flow uses skeuomorphic design to make the credit card look like a real card, but it’s just confusing. And you can’t copy and paste your card number from a different document.

There are more issues, but that’s not really what this post is about. This post is a call to cutt off Flash as a primary development technology on a web site, not just because it’s slow, difficult for SEO, doesn’t work on iOS, and all the other technical arguments against it.

We need to cut off Flash mostly because it makes it way too easy to design bad user experiences. The web is undeniably moving beyond Web 2.0 (whatever that was) and into an era where simple designs that put content first provide the best user experience. And Flash simply doesn’t fit that mold.

The struggle between Writing and Design, or Why everyone should write

[caption id=“attachment_1181” align=“alignright” width=“240” caption=“Thinking about writing at Melissa’s Food Shop, Cape Town.”][/caption]

How good I am at my job as a software Product Manager depends on my ability to do two things: Understand the needs that real people have when they go online (whether they can articulate it or not), and building products that satisfy those needs as well as meet business goals. It occurred to me this morning that in many ways writing is about doing the exact opposite. To a large extent, writing is about being selfish.

Virtually any book or article you read about writing gives the same advice: Write what you know and what you’re passionate about. Write what’s in you, not what you think people want to read. Just last week James Shelley reminded us that people cannot help but notice an individual with passion. In another post he says:

Although passion may at times appear dangerous, the planet does not need less human passion right now, it needs more passion than ever before ”” passion that refuses to be immunized by the lulling caress of consumption and the crippling inundation of knowledge.

But it is this apparent struggle between Design and Writing (with a big D and W) that makes it so damn difficult to write sometimes. As user experience designers we’re trained to get out of our own shoes and into those of others. It’s about their needs, not our likes and dislikes. “You are not the user,” we often say.

But I have a feeling that the best writers (and designers, for that matter) are those who are able to balance this apparent conflict between user needs and internal passion effortlessly. Writers and designers who truly astound us with their work are those whose understanding of what people need are so ingrained in their beings, so much part of them, that they’re able to express their passion in a way that meets those needs “without fuss or bother,” as the NN Group definition of User Experience states.

It is for this reason that I think if you’re in software, you should write. Anil Dash got me thinking about this when he said:

Some ideas are just bigger than 140 characters. In fact, most good ideas are. More importantly, our ideas often need to gain traction and meaning over time. Blog posts often age into something more substantial than they are at their conception, through the weight of time and perspective and response.

If nothing else, the practice of writing down your thoughts (yes, about the things you are passionate about) will teach you how to create words in a way that resonates with those who read it. And just go ahead and try to convince me that won’t make you a better designer.

The biggest problem is, of course, that we all hate our own work, especially in the beginning. As Ira Glass so eloquently puts it:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit.

He goes on to give this advice:

And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.

If you’re noticing a change in this blog over the past few weeks, you’d be right. I’ve redesigned to put the focus on the content, and I hope to write just a bit more - even if that means fewer long-form posts. I have to test this theory that writing better words will help blur the lines between what I’m good at and what people need from software. We’ll see how it goes.

And you - yes, YOU. Go write something, ok?

Humble Design

I’ve been thinking a lot about the importance of humility in design. About a month ago David Gillis said the following in a great article for UX Magazine:

When it comes to designing experiences, cultivating a humble approach is absolutely essential. The sheer complexity of the design challenges we face demands open-mindedness - a willingness to test and modify assumptions, to make mistakes and be proven wrong.

Humility is about knowing what you don’t know, and when it comes to dynamic, interdependent, multi-platform systems, there are an awful lot of unknowns.

And then there’s this tweet by a good friend that’s been on my mind for a while now:

Humble

Ain’t that the truth.

But let’s also clarify: I’m talking about true humility here. Not the “Oh, I’m so humbled by your praise so let me retweet it to all my followers” humility. I’m talking about the humility that comes from realising that Design is about meeting user needs, that it’s a study of human behaviour so if any of us want to call ourselves experts at it we are sorely mistaken.

I didn’t think that a medieval monk could teach us much about design, but I recently stumbled on a quote by Thomas Kempis that brought this whole concept home for me:

A true understanding and humble estimate of oneself is the highest and most valuable of all lessons.

Should you see another person openly doing evil, or carrying out a wicked purpose, [or launch a really bad website,] do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.

We are all frail; consider none more frail than yourself.

I don’t think this means we should stop being critical when we see bad design. But I do think it means we need to criticise with the aim to contribute to the design community, not break it down. If we learned anything from the Dustin Curtis “Dear American Airlines” story, it’s that we cannot possibly know why people make some of the design decisions they make.

So let’s help each other out, is all I’m saying. Because one day you might put a bad design out there, and all you’ll ask for then is a little advice and lots of grace.

The problem with fluid layouts, summed up in one screenshot

We’ve received quite a few questions about why we changed kalahari.net from a fluid layout to a 960px fixed width layout. There are pros and cons to both approaches, and Smashing Magazine did a great job of explaining those trade-offs in Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?

For me, the most important reason to use a fixed layout is that it allows you to have full control over the experience and what the user sees on the screen.

But since a picture is worth a thousand words, I guess you can sum up the problem with fluid layouts with a single screenshot:

Little UI details: Twitter iPhone app's clever solution to Reply / Reply All

The Twitter iPhone app is getting a world of criticism right now, and I have to say I agree with most of it (for an excellent overview and analysis of one of the main issues, see Why the Quick Bar is still so offensive). But let’s also give credit where credit is due. As Little Big Details has shown us - sometimes small UI touches can take a user experience from “meh” to “awesome” pretty quickly. And I think the Twitter iPhone app’s implementation of replying to a tweet with multiple users in it does just that.

If you respond to a tweet with two or more usernames in it, you technically need two options: Reply (to reply just to the person who wrote the tweet) or Reply All (to mention everyone that’s mentioned in the tweet). So, two buttons needed, right? Not in the Twitter app. There is just one icon to reply to such a tweet, and the screen you get then looks like this:

The screen automatically selects all users that appear directly after the user who wrote the original tweet. So in essence the reply button gives you three options:

  • Just start typing if you want to erase other users from the tweet and just respond to the original user.
  • Place you your cursor after the original user if you want to /cc the other users.
  • Place your cursor after all users if you want to write a traditional “reply to all” tweet.

This is such a small thing, but I can guarantee the implementation was a deliberate design solution to a specific problem:

How can we reduce the need for a Reply button and a Reply All button while at the same time improving the user experience?

Little details like this should inspire all of us to sweat the details and not go “Ah, that part doesn’t matter, it works fine, right?”

Improving usability with the visual design principle of Proximity

One of the most often violated principles of visual design is, ironically, also its simplest — the principle of proximity:

Put things that are related close together, and space things that need to be seen as separate

One of the more extreme and frustrating examples of this can be found on the online banking site for ABSA (a South African bank):

The problem here is that if I select a beneficiary from the list I have to click the “Next” button that is at the bottom of the screen — far removed from the action I took in the dropdown. Instead, the “Add new” button, used to create a brand new beneficiary, is in close proximity to the dropdown, and therefore gives the sense that the dropdown and the “Add new” buttons are grouped together. The solution to this problem is so incredibly simple: just switch the buttons around.

Another example I came across recently lives in Outlook for Mac 2011. Let me first say that as much as I’m not a fan of Microsoft, Outlook for Mac is still so much better than any version of Entourage, so for that I am eternally grateful. But the implementation of email search really needs some work.

Say, for example, I am looking for all emails that include the term “Clicktale.” My starting point is this text box, which states that I will be searching the current folder only. I knew that the email I was looking for wasn’t in the current folder, but on hover an additional message told me that after I searched I’d have the option to expand my scope, so I wasn’t too worried:

Things got tricky the minute I started searching though. As I typed, a dropdown appeared:

The email I was looking for had the word “clicktale” in the body, so none of these options applied to me. I didn’t know what to do, so I just stopped typing, wondering what to do next. Well, suddenly all email disappeared from my Inbox (current folder), so I assumed that meant the search somehow happened. But there was no feedback about this, I had to figure it out based on my knowledge of what’s in the folder and what I was looking for.

Well, ok then. Now to figure out how to expand the search to more folders. First I went down a completely wrong path. I clicked on “Advanced”, and found this dropdown:

Hmm, no good. I needed to expand to different folders, so clearly this was the wrong direction to go. I started over, and after much searching, found the “All mail” button. Can you spot it below? (Click to enlarge the picture)

Even by pointing out what you’re looking for, and removing some of the clutter in the rest of the page, I bet it took you some time to find it. Why? The design principle of proximity. The filtering action is so far removed from the search box where you type that your mind just doesn’t make the appropriate grouping.

Now, I appreciate what the designers tried to do here. Instead of presenting you with all options upfront they designed a good experience for the majority use case (searching within the same folder), and used progressive disclosure for advanced usage after the initial search is done. But by breaking the principle of proximity this results in a big reduction in usability.

These are two quick examples, but keep an eye out for proximity issues as you browse the web this week, and let’s make a point of adhering to this principle in our designs. There are so many hard usability problems to solve that we really should make use of the easy wins. This is one of them.

Read more about the proximity principle: