It’s easy to think I work in an an exciting, dramatic field that’s always pushing the boundaries of what’s possible, and continually reinventing itself in new and better ways. Users love the web, right? We’ve done a great job, haven’t we?

The thing is, somewhere around 2006, the web stopped growing. Web designers in general started to become increasingly more complacent and frankly bored with their jobs. Making a web app? Okay, plug in the templating framework of your choice, set it to CRUD mode, code up an HTML form and stick a JavaScript library on top of it. Content? Who needs it! Just hook it all up to Twitter, FaceBook, Flickr, Google Maps and hell, maybe some RSS feeds too. The design has to be catchy enough to get users interested, but don’t worry too much about making it usable. People will just be plugging in to it through their phones, desktop clients, or RSS readers.

Hello, web professionals. Welcome to the future. No wonder the conferences have degenerated to a stream of excuses as to why a full quarter of the world is still using IE6. And there’s an uncomfortable amount of silence regarding anything new. There is nothing new – and there hasn’t been for three years now. The big voices have fallen silent, and no one is rising up to take their place.

The problem isn’t the web. The problem goes much deeper than that. Our interface metaphors are flawed, our input devices are outdated, and the essentialization of most human-computer interfaces, on the web or in your OS, boils down to this:

No, no, no. People, we can do better than this. AJAX doesn’t make this right. It might make it feel more responsive, but at the end of the day it’s still just data entry.

The next time you design an interface, pretend your user doesn’t have a keyboard. What if all they had was a confirm button and a cancel button? This is basically what most game interfaces are. What about the iPhone? It has a keyboard, but only nominally. iPhone developers can’t rely users being willing to deal with the keyboard, and they have to be more creative with their input methods.

The restriction of having no keyboard has driven a lot of innovation on both game consoles and mobile devices. Where is that innovation on the web? Why are we still treating this thing like a terminal running Lynx? (And don’t you dare blame the browsers. You can do better and you know it.)

Here’s a thought experiment for you. Design an IM client that does not take input from a keyboard. (And I’m not talking about voice recognition here either. That’s not allowed.) After about five minutes of thinking about how awful and tedious that would be, you might be surprised with what you come up with. Maybe it could work like a conversation tree in a video game. Or maybe you could select a mood and a topic and it would automatically generate speech for you. Or you could go the abstract route and come up with an entirely different conversation model than what we do in person, leaving written language completely out of the equation. The sky, as they say, is the limit.

Give it a half hour of thought and you might actually get excited about it. Why? Because you’re tired of this nonsense too. We all are.

Rule #1 is that you must be communicative about your expectations and preferences. If you hate blue shiny things, say you hate blue shiny things. Send your designer examples of art you like. If he requests more information or feedback, give it to him. If you want his opinion on something, tell him that. I know you’re thinking, “But I’m hiring a designer because I don’t know about this stuff!” And that’s true. But he is trying to help you realize your vision, and you’re both likely to be unhappy with the results if you don’t communicate your goals.

2. Don’t be afraid to say you don’t like it.

This happens to everyone. Your designer works all night on a mock-up and it just doesn’t sit right with you. Maybe he does a couple more revisions and it still isn’t working. The more he works, the harder it can be to say it’s not what you’re looking for. But remember that your designer is (probably) a seasoned professional. Believe me, he is used to criticism and negative feedback. It will not hurt his feelings or make him discouraged. When you say you don’t like it, he’ll know he’s going in the wrong direction and try something different. Unless he truly is a one-trick pony (in which case you should probably find a new designer), your honesty will help him do his job better.

3. Be as specific as possible in your feedback.

One nice thing about working in the world of digital art and media is that our work is no longer nearly as static as it used to be. Imagine a painter in 1829. If you commission a painting and you don’t like how it comes out, he has to start all over again. He can’t go back and make the sky purple or have the subject face the other direction. By contrast most contemporary designers and artists create their work on a computer in the form of large, complex multi-layered documents. Relatively speaking, these are incredibly easy to change. Elements can be added or removed non-destructively. Colors can be changed on a whim.

When you send feedback on a revision, don’t just say “I don’t care for the headers.” Instead, say what you like and don’t like about them. An example might be, “The font is good, but they don’t pop enough.” A designer will know what to do with that, and more importantly they will know what not to change.

4. Leave some room for creative space.

Unless you’re just hiring a Photoshop jockey (and I hope you aren’t), try to remember that your designer is not just creating deliverables but also coming up with ideas for you. They are thinking of creative solutions to your problems and looking at your company or product through the lens of usability, branding, or aesthetics. This process involves research, mental energy, and most importantly time. When you have a timeline, make sure your deadlines for deliverables and milestones are clearly communicated at the start of the project. And then leave them be! Don’t ping every day asking to see “how it’s coming.” If they even have something tangible to show you, they won’t want to. Give them room to come up with something great.

5. Remember they have your best interests in mind.

This one’s important for dispute resolution. It’s true that the customer is always right, so a paying client can usually win any dispute by pulling out the “who signs the checks” card. But it probably isn’t in your best interest for you to do this.

When your designer disagrees with you, it’s his professional responsibility to explain why. Even though he does creative work, it is still ruled by logic, research, and experience. If he doesn’t want to do things the way you wanted, he probably has a reason that he thinks is aligned with the goals you expressed to him in step #1. It’s your right to ask for this reason and to spend time talking it out if you need to. But insisting on something on principle, without regard for your designer’s judgment, is a waste of his talent. He’s not your enemy; always assume that he is trying to help you.

I hate design portfolios because they are a symptom of a myth that helps no one. The myth is that a designer’s portfolio somehow gives you insight into how well that person does their job. This is about as true for a portfolio as it is for a resumé. Neither tells you the important information about a person, and if you are thinking about hiring a designer you should be aware of what you’re not seeing.

Myth: The portfolio showcases the designer’s sense of style.

If the designer is at all experienced in their field, their portfolios will represent their clients’ tastes more than their own. Any creative professional who imposes their own style onto their clients isn’t doing their job very well. Every client needs something different, and portfolios do the injustice of removing the work from the context of the project or brand identity it was meant to be a part of. The designer used their judgment to create something that suited the needs of their client. They may not even like it very much, but that doesn’t mean they didn’t do their job well.

Myth: Great designers will make a great portfolio for themselves.

The slicker the portfolio, the more time the designer has on their hands. Think about that for a moment. A talented designer in high demand is using their creative energies on their clients, not themselves. This is why you see spectacular portfolios on people coming right out of school. College gives you the time to fritter away tweaking your personal site, but the real world doesn’t. Most top designers don’t even maintain one (Jeff Veen, Amy Hoy, and Jesse James Garrett, among others).

Myth: An attractive portfolio indicates a good designer.

Have you ever worked hands-on with a designer? If so, you probably understand that the final work is a product of their ability to work with you and to extract the essence of what you need from your head. A portfolio is a bunch of static images on a page. It doesn’t tell you one whit about their ability to work with you. This is why people test drive a car before buying it. It’s not enough for the car to be beautiful; it has to work the way you want it to or you’re just going to be unhappy with it.

Myth: The portfolio shows you what a designer has worked on.

Wrong, wrong, wrong. The portfolio shows you what a designer has worked on, and is allowed to post publicly, and has actually shipped, and is visual in nature. This is likely a small portion of what they have actually done in the course of their career. Sometimes a designer sells all rights to a work and can’t use it for self-promotion in any way. Sometimes (often) the project they worked on never saw the light of day. And let’s not forget the important fact that most of what a designer does is research. They talk to their clients, they analyze competitors, they draw diagrams and sketch and make flowcharts. None of this critical planning makes it to the portfolio, but could easily represent six months of work.

Okay, so how the hell do you hire a designer then, if the portfolio is so useless?

The same way you hire anyone. Treat their portfolio like you do a resumé. It’s a good start for screening, but it doesn’t give you enough information to decide between qualified candidates. Try conventional hiring approaches to get a better sense of who they are.

1. Have a quick interview with the designer. They should be willing to answer some questions over email or the phone. It almost doesn’t matter what you ask them; what matters is how well you can establish a comfortable conversation and mutual understanding.

2. Google their name and look for blog entries or articles they have written. You can learn a lot about a person this way, as well as gain a sense for how they approach their work. Are they active in communities related to their field?

3. If hiring for a long-term position, try a trial project or contract-to-hire situation. (Thanks Daniel Jalkut for this idea.) There’s no substitute for actual hands-on experience working with someone. But be aware that not everyone is willing and able to do this sort of thing, and it shouldn’t be a strike against them if they aren’t. It’s a more situational evaluation tool.

4. Ask for references, and actually contact them. You can afford a few minutes to fire off some emails, and this feedback can be critical to your decision.

A word to designers

Ya know, I hate to say it, but portfolios are still a necessary evil, at least until you are famous enough that your clients are willing to take it on faith that you’ll do a good job. But responsible clients will want to see more than that.

Don’t sink all your time into it. Don’t redesign it constantly. Start simple and keep it simple. Make sure you have a traditional resumé and keep it linked in plain sight. When you can, give a few words of context about the project. And then let it go. Focus on your work, not your image.

And on that note, I should get back to it. I promise I won’t work too hard on it. After all, I’ve got better things to do.

This editorial interested me because I struggle with the same issues as a designer at Google. I’ve watched the web 2.0+ world evolve around us, but our design mentality remains rooted in the early days of the web. Black text, white background, blue hyperlinks. And it’s not just Google and Jakob Nielsen – this aesthetic persists all over the web, despite many designers’ attempts to banish it forever.

Speaking for myself, the sites I use every day are still very much in line with Nielsen’s view of good usability. Google web search, Gmail, Reddit, Wikipedia, Twitter. Black and white and blue all over. Why does it work?

The interface needs to stay out of my way

Every application has a function. Assuming that function is well-implemented and something that I need to use, I will want to use that application. The interface should only be a tool that helps me get to that functionality. The moment I have to think about the interface – even to marvel at how cool the drag animation is – the application has failed in it’s primary purpose. It exists for the function, not the design.

“Now Anne,” I can hear you saying. “What if the point of my application is the experience? My Flickr/YouPorn/Facebook mashup is super-slick and fun to play around with. I get like ten thousand hits a day!”

Okay, yes. These apps do exist, and should exist. They can be anything from neat toys to richly detailed digital adventures. I’m not really talking about these kind of apps, because a user isn’t really trying to do anything with them. They are there simply to experience it.

When you have problems is when you get the bright idea to make your practical application, say a webmail client or a news aggregator, and make it “experience oriented.” A rich, novel interface can certainly give your site impact and memorability. I might tweet about how cool it is and it will probably generate a lot of interest and hype. These are good things, but they reside in the sphere of marketing, not usability. Designing for the launch is a mistake. Getting people to log in on day one is only half the work; getting them to stay is the other half. You want them to come back every day and the novelty of the rich user experience is only going to last so long. When it wears off, can they do what they need to do on the site quickly and easily?

Yes, latency is still an issue

…unless your target demographic really is rich, technologically savvy people with fast internet connections in the United States. Hey, it might work if your margins are really high, but if you’re writing a web app, chances are good they aren’t.

Reddit is… well, Reddit, but I keep going back to it as a source of things to read because it does what it does and stays out of my way the rest of the time. It is literally just a list of links on a page, which is exactly what I’m looking for. I want a service like that to load instantaneously, because I’m likely to hit it many times throughout the day. Waiting for an image to load annoys me. Waiting for a page full of them makes me want to go somewhere else.

If your app is going to have a rich artistic element, it had better damn well be customizable

Imagine if Apple set your desktop image for you. You use your computer every day, and even if it was the most beautiful photograph in the world, you would get pretty damn tired of that image. This situation sounds ridiculous when talking about client products because it’s well known in that world that customization is an important part of a happy user experience. I don’t understand why web developers haven’t picked up on this yet.

iGoogle is a good example of how to do this right. This is an application you’re meant to keep open in a tab all day while it pulls in news feeds and tracks your email and whatever else you configure it to do. When they realized iGoogle wasn’t exactly the prettiest thing to look at, they added user-customizable themes with colorful, rich banner images behind the Google search box. Even better, the image changes throughout the day, so every time you click over to that tab to check your email you might see something different. The end result is that it takes a while to get sick of a theme, and when you do you can always just switch to another one.

User experience is not all about the clicks, but revenue is

You don’t have to take my word for any of this, you know. You can use any number of free tracking tools (Google Analytics and Website Optimizer are my favorites) to learn more about the behavior of users on your site and run experiments with the design. Usage statistics certainly can’t tell you everything – they can’t tell you if your users are happy, for example. And there are some pretty ugly and/or misleading things you could do that would almost certainly increase the number of conversions on your site. I’m not trying to tell you to do these things. The negative impact to your overall user satisfaction and brand would not be worth the increase in clickthrough.

Even still, you have to be running these numbers and aware of them if you want to be an effective designer. “But the green links make users feel good!” is not an effective argument if blue links increase clickthrough by 5%. ROI is not a dirty word; embrace it, and if you keep a record of the data you collect and the tweaks you make, you’ll have a lot of ammunition handy when talks of a redesign come up. The first question you should ask is “What problem are we trying to solve?” and the second is “How can we prove that we solved it?”

The moral of the story

“So Anne,” you ask. “Can I use images or what?” The answer is, it depends. Pretty graphics and colors and AJAX and slickness are all great, when they don’t get in the way of what your app is supposed to do. No matter how you approach it, things that are clickable should be easily identifiable as clickable. Things that are meant to be read should be clear and easy to read. I’m stating the obvious here because it is the precise reason the text + hyperlinks paradigm is powerful and shouldn’t be overlooked.

Just look at Wikipedia. In many ways, it is the perfect web application. How empowered do you feel when you use that site? You have easy access to almost anything you could ever want to know, and anybody who has used a computer in the past twenty years can figure out how to navigate it. Even my grandmother knows blue underlined text is a hyperlink. It’s a big flag that says “you can do something here!”

Now, I know you need AJAX and pretty gradients and buttons to make your webmail client usable and attractive. Do what you have to do to make it work, but at that point you might want to ask yourself if the web is the appropriate platform for that application.

Remember, design is equal parts marketing and usability; approach it as such. Be pragmatic. Don’t mindlessly decorate. And don’t be afraid to use what you know works – even if you are in danger of Valleywag calling out your “so 1990s” design. Own it!