Removing ego from design

One of the most difficult aspects of any web design project is reconciling the goals of the designer with the goals of the audience. (And by "designer," I am including everyone involved in the design process, including the client, the design agency, etc.) This is so difficult because the goals of the designer include so many facets -- the client wants to get more money coming in, the agency wants to please the client to get more work in the future, the creative director wants to wow other creative types with his/her vision and maybe win an award, etc. And amidst all of that as well are political power plays, internal arguments, and some "selective hearing" when it comes to research and statistics that don't support their individual goals. (I speak of no particular agency or experience here -- these are accumulated observations.)

The whole rigmarole can be a bit exhausting and it is very easy to get caught up in the "designer" side of things. It all seems quite serious - to step back and think about the fact that people can get into shouting matches over a single word on a website (I've seen it happen) - I don't know, it seems like the perspective is off. People take these battles very personally, and fight for things because they want them, or because it means something to them, and it's easy to forget that all that really matters is whether or not somebody going to your website is going to have a good experience.

This is why I've found it so valuable, in my own work, to start viewing the work I do as completely separate from who I am. Much of what I design is based on research - knowing what works and what doesn't - but there is not enough research in the world to make every decision foolproof. If something was a subjective call, or I designed based on a hunch, and someone takes issue, I'll explain my viewpoint but recognize that if I don't have an empirical study to back it up, it's really just an opinion.

In addition, when working in a group environment, letting go of ego can make the brainstorming and overall creative process a lot more open. An idea prefaced with "this may be stupid, but..." could end up being the best idea of the day, while one that someone thinks is surefire could be quickly tossed out as the details are thought out further. When ego is involved, the initial "stupid" idea might never be brought up for fear of a negative reaction, while the "surefire" idea might be fought for tooth-and-nail to the detriment of better options. Letting go of ego - where you perceive comments about your idea as a comments about you - switches the emphasis to the ideas, not the people.

This ends up being quite liberating in the long run, because not only does it make it easier to edit and adapt your design as more learnings come in, it also makes you focus more on what will best serve the end user. And in the end, that's really the truest measure of a successful design.

Trust and faith in design

It's a cliche to make fun of older generations and their discomfort with technology, but that stereotypical technophobia is really just an extreme version of something all of us probably feel at some point or another: a lack of trust and faith in the system we are using.

What does this button do?
I remember having someone ask me, "What do I do to submit the form? Do I press the submit button?" The answer, to most of us, is "yes, duh." But what if the question is less clear? Navigational terms don't match what you thought you'd find. Something you thought was a free trial asks for your credit card and doesn't explain why. A link that seemed obvious takes you to a completely unexpected page or site. In each case, the design is playing fast and loose with the user's trust and faith, and as a result, is probably failing the user's needs.

Anticipate the next step
Good design anticipates what the user will want. On your homepage, offer links to the things your visitors most likely will want. Look at the search terms people use to find things on your site, and make sure your navigational terms match them. Whenever you ask a user for information, explain why you want it and how it will be used.

Explain yourself
One place that I frequently see abused is the "contact us" page -- many sites will ask for name, address, phone number, email, sometimes even fax number and company, and in worst-case scenarios, they'll even tack on some "survey" type questions -- even if all you wanted to do was maybe email them to ask about the release date of an upcoming product. In that scenario, literally the only piece of information the company actually needs is your email address. So why ask for the moon? Is it because your designer just used a "contact us" template and didn't really think about what that means for the user? Is it because you are adding me to a database you are going to sell to third parties? And even if all you do ask for is my email address, will you start sending me unwanted email newsletters without asking? Tell the user up front, and let them make the informed decision. (Even better, in this scenario, you could save the user and yourself time by having just clearly listed the product release date on your site in the first place.)

Expect questions, and provide answers
One thing I try to do when starting any project is just write down a list of questions I think a user/visitor may have, based on the type of site/product and the customer base. I try not to get overly specific but the questions should not just be the broad ones either -- for example, on a shoe site, I wouldn't write out questions about a particular pair of shoes, but I might write out questions about broader types of shoes, or questions that might apply to any individual pair of shoes.

Prioritize and group logically
From there, I try to group the questions logically, and see if they align to particular terms. If possible, prioritize the questions as well, and make it easier to find the answers to those more essential questions. This is also where some statistical data can come in handy -- search terms used, frequency of visits to particular areas of a site, volume of support emails/calls about particular topics. Maybe half the visitors to your site are just trying to find your address, and already know all about your product/service. You could have a beautiful, highly usable presentation of your product line, but if that address is hard to find, you are failing half your audience from the start.

I've found that structuring a website around this is a good way to meet user's needs, and a lot of this work can inform other decisions down the line, and make it easier to work in changes/new ideas -- just follow a mini-version of these steps (asking questions, grouping them, working out logical answers) and see if your architecture already accommodates these changes or if you need to restructure.

By anticipating everything the user will want, and providing easy answers to key questions and presenting them at logical points, you build that trust and faith. You're more likely to have a happy customer, and you reduce anxiety.

Beware the permanent brainstorm

There is a particular type of person out there who is very creative, who loves to come up with new ideas, who gets excited about a new concept they think could be really successful or beneficial. These people are vital -- without them, many (if not all) of the big ideas that have changed our lives would never have happened.

But there is one flaw that often comes hand-in-hand with this level of creativity and brainstorming. For every Steve Jobs (Apple), Bill Gates (Microsoft), and Mark Zuckerberg (Facebook), there is that friend you have who is convinced that adding zipper pockets to suspenders is the next big thing. Or maybe that was last week, and now they're pitching tiny umbrellas for cellphones. In any case, their mind seems to always be working, but never carrying through the thoughts to something that is not only a great idea, but one that they can (and do) actually implement. I call this the danger of the "permanent brainstorm."

Those examples are extreme, but I believe there can be a real danger to focusing so much on the brainstorming and "ideating" portion of a project that you never get off the ground and develop something real.

For a more grounded example, consider a project where a company wants to come up with a new marketing website. All they know at first is that they want to target a new audience that they don't currently speak to. The brainstorming phase begins, and the team narrows it down to one particular concept.

This could go two ways -- the team could further focus in, delineate their ideas, and develop them into a site and get it live.

Or they could just keep brainstorming. What if we broaden it to include this other audience as well? What if we focus more on the interactive games? What if we switch from an edgy/rough look to a clean/modern look? And then after trying all those alternatives, they keep spinning around to other ideas. A hot new competitor site shows up halfway through the project, and they want to take some of the competitor's ideas and re-think the original goal.

You get the picture. The ideas keep coming, the project keeps changing, people second-guess their original ideas and the whole thing continues to mutate and shift even as it's supposed to be nearing its completion. The budget has swelled, the timeline has been shot, and corners are being cut that could make the difference between something great and simple and something overly ambitious and complicated.

Of course, this is not to say that brainstorming is bad - as I mentioned before, it's the brainstormers who come up with all the big new ideas. The key is knowing when to shift away from generating more ideas and shift toward refining and implementing your original idea. It can be scary sometimes to do this, but it's all about putting a stake in the ground and saying "this phase is done, we need to move on to the next phase, or else we're going to get stuck."

That can be a hard thing to do. Nobody likes the idea of setting something in stone when they are anything less than 100% sure of it -- and rarely is any new idea a 100% bet. But this is where handy metaphors and sayings run short -- unless you are engraving tombstones, you're not literally setting things in stone. You can make changes later on if need be -- it's just important to respect that those changes should be based on fully reasoned thinking, not whims, or a dream you had last night, or what your 5 year old said when he saw a mock-up of the project.

Be excited. Think wildly. But recognize that as part of any project, brainstorming is just step one. It takes a lot of work to turn a good idea into a good product, and you'll never get to a successful end if you never leave step one.

"In a perfect world..."

Most design agencies are structured into silos, with people specialized in different aspects of the design and management. I wrote about some of the problems this can create in an earlier post, but there's another aspect to specialization: we expect people in later stages of the process to be able to fully realize the ideas we have as designers earlier on in the process.

I have seen too many times an idea get implemented either without the interaction/design fully realized, or just plain implemented wrong. The results are almost always disappointing, and sometimes that seemingly small difference between well-polished and rough-around-the-edges is the difference between easy and frustrating. A poorly-implemented great idea is often worse than a well-implemented mediocre idea.

This is a tough situation to deal with, because often you won't know if the idea fails in implementation until it has actually been implemented, and at that point it may be too late to try an alternate approach. And even if you know it is risky, sometimes it is worth the risk. My best suggestions?

Make a sample version/functional prototype
Try to create a mini version of your big idea. Problems may rear their head that you didn't expect, while things you expected to be difficult may work out smoothly after all. In either case, it should tell you if it is worth exploring further or abandoning.

Do it yourself
You can't always do this in a large agency (in fact, you probably rarely can), but one of the benefits of working small or being an all-in-one freelancer is that you know fully the skills and knowledge of every one at every step -- because it might be you in every role. You may not know every single aspect of how to create something in advance, but it's important that you at least know how to learn everything needed, and that you can do it within the scope of your project.

Have a well-thought-out Plan B
Sometimes your Plan B may just be an earlier brainstorm that wasn't fully realized, but just as you should design for user failure, you should design for designer failure too. Unexpected obstacles are common, and the more ready you are with an alternate approach, the more likely your end result will be successful. Trying to patch up a sinking ship that has been battered and bruised may be a mistake -- sometimes you just need to scratch that ship and build another one. If you've got the blueprints for the second ship available already, you'll have a head start.

I've half-joked before that I want to become a "reality consultant" -- someone who can look at all the big ideas and plans and offer some cold hard reality about what is or isn't achievable, what will be simple or difficult, and ultimately where energy should be spent to really ensure something good in the end. But until that is a real job, we can all be our own reality consultants and be ready to adapt if our "perfect world" vision doesn't come to fruition.

The shackles of innovation

It's a word that has lost virtually meaning due to its constant repetition: innovation. Any number of industries must hear this word all the time -- it seems like the single most important thing to just about everyone. Is your product, or site, or approach innovative? If not, it might as well be worthless. Everyone is trying to "think outside the box" (a phrase so cliched at this point that even putting it in quotes doesn't give it the ironic distance it deserves). There is a widespread assumption that the status quo is bad, the way we do anything today is inferior to some "new" way we've yet to discover, and the search for this "new" way should trump all other efforts.

I can't agree with any of that. Striving fervently for innovation strikes me as severely misdirected effort, not because I believe innovation is bad, but because I think it is a side effect, not a goal unto itself.

The biggest problem with focusing solely on innovation, in my mind, is the assumption that current ways are bad -- it is starting with a ground floor decision to disregard all the prior work done by those in your field to get you where you are today. It is certainly true that previous work may have been done based on faulty information, incorrect assumptions, and other ill-advised decisions that could have brought things to a highly imperfect state today. But it is by no means a guarantee -- in fact, the opposite could also be true. Your product/site/whatever could be the way it is today because of highly reasoned research and testing that led to it being extremely solid and well thought-out. Unless you know all this background already, you can't really claim that innovation is necessary.

Focusing solely on innovation also sidesteps what should probably be the true goal of any project - to make the best product/site possible. A thorough process will explore the tried and true ways as well as newer, more innovative approaches. In many cases, more standard, "non-innovative" methods may prove to be the best fit.

Let's say you create a new site or product and all your testing and research leads to a conclusion that your best bet is to rely on well-established techniques. Had your goal been solely to innovate, this project would be a failure -- you've created nothing innovative. And yet, you've created the best possible product/site for your users -- the only problem was that it didn't involve creating anything truly new, just using existing principles to their greatest effect. How could that be bad?

Now let's consider the converse situation. Rather than seeking innovation, your goal at the start of a project is solely to create the best product/site possible. You do your brainstorming and research and find that the best solution is one that DOES in fact use a new, innovative approach -- it is thoroughly supported by your testing. No one would call this project a failure, and by focusing on making the best product/site possible, you've now overdelivered by also finding an innovative approach in the process. Innovation was not the goal -- it was icing on the cake.

There are a lot of reasons why innovation is still such a prized asset -- it's sexy, it sounds good, it shakes designers out of their boredom -- but these are not enough to warrant prizing it above quality. Think you've got a better way to do something? By all means, explore that new method and see if it works better -- but be willing to recognize the value in also learning that it's possible an existing method is still superior.

I should mention that this post is partially inspired by Scott Berkun, who I saw speak at the UI12 conference in Cambridge, MA, in 2007. He spoke about the "myths of innovation" and mentioned, for example, how innovations are often accidents, and he also talked about how the word "innovation" has indeed lost a lot of meaning over the years. I don't claim that this post represents his opinions at all, but his talk came back into my mind as I worked on a recent project that was driven by a client's desire to innovate. Check out his blog, it's got some good stuff.

Objectivity is a dying art

It's hard not to notice, as the US moves into the final days of election season, how increasingly polarized a lot of people are. Making an objective assessment of anything seems to have gone out of style, and I think it's to our great detriment.

This blog isn't about politics, but I think this concept of turning every decision into a battle has carried over into many aspects of our lives, including management and design. Take, for example, a designer who believes strongly in simplicity and reducing clutter (as I do). You'd think the best way to put together a recommended design in that instance would be to analyze what's needed and suggest a minimalist design that still offers all the necessary functionality. But I've seen situations where, expecting push back from a client to add more, the minimalist-leaning designer ends up recommending something that is even more scaled back than they believe it should be. If their design were approved right off the bat, it wouldn't even be what they want. They expect an equally opposing force to fight them, and hope that they land somewhere that looks like their actual recommendation.

The end result is that rather than working as teams to accomplish the best work possible, each faction takes the core of their suggested beliefs and recommends an "extremist" version of it, believing that it will be watered down over the iteration process to hopefully land somewhere close to what they really think is best. Everyone becomes an advocate for a particular strong viewpoint, and the end result is not so much a happy compromise as it is a series of concessions. We deliberately don't look at things objectively because we think, "well, if I'm objective, and the other person isn't, I'll lose so much ground that my stance will be lost." We turn off our objectivity, and sometimes don't even know why we're fighting for things anymore, except that it seems like it's the side we should be on. Sometimes the other side does have a good idea -- a better one than you had -- and we should embrace those as learning opportunities rather than as "giving in."

This process doesn't usually end with a happy solution. It ends with something everyone feels moderately comfortable enough not to continue fighting over.

I don't have any particular proposition for how to change this, beyond just trying to foster objectivity more in your own work. I try to look at my own designs and ask, "is this really the best way?" Sometimes I'll do a full design on something and scrap the whole thing because, after stepping back, I realize my initial assumptions about the best design were off track. I try to listen to critical feedback and objectively accept when that feedback is right. If I love something, but everyone who sees it is confused by it, it's irresponsible of me to ignore that -- I try to figure out why my instinct was off and how I can adjust to avoid making that mistake again.

I'm not perfect at this by any means, but I do value objectivity and think it's to everyone's benefit to be a little more willing to stand back and take a critical look through someone else's eyes. You might see something you never thought of before.

How much can you know?

Confession time: I don't know everything. I know, you're shocked. But seriously, I was talking with a couple friends who are in web design, shooting the shit about various techniques and CSS and JavaScript (you know you're a nerd when...), and at one point I blurted out, "sometimes I feel like I don't know nearly as much as I should and I'm just making it up as I go along." My friend, who has had a few years more experience than I have, didn't miss a beat: "You just described everyone in our industry."

That was comforting, and probably true, as there are so many different things any individual could know in the field of web design that it's pretty much impossible to expect anyone to know it all. I'd argue that the greatest advancements in design have come from people who were making it up as they went along.

It seems to me that a good designer -- or perhaps more specifically a coder/developer -- doesn't necessarily need to know how to do every idea or assignment that comes their way. They just need to know how to LEARN how to do it.

I'll give an example of a recent project I did. There were a number of techniques I wanted to do, yet didn't know specifically how to do them off the top of my head. Among them: tabbed content within a page (rather than clicking to a new page for every tab), an automatic rotating image slideshow, a form that calculated various fees and totals in real time as you select different options, and a method to display content only if it exists on the server and how to present an alternative if it doesn't -- these are all things I had never done before, but knew I could figure them out, and I managed all of them successfully. Admittedly these are smaller features, and allowed me to learn in chunks rather than being presented with something as complex as "build us an online stock trading system." I felt confident tackling them because I at least knew enough about the various languages and techniques involved to know that they were all achievable, and as I worked on them, I learned more about other underlying concepts that will help me with the next new idea/design.

I think too many people, when given a challenge they don't already know how to complete, simply give up and think it's outside of their abilities. This is rarely true. There are still coding languages and techniques that seem so complex to me that I can't help but feel intimidated -- but breaking them down, and remembering that everyone who is now an "expert" was once in my shoes as well, has made me realize that knowing "how to know" is a skill that lets you do just about anything.

Thinking too far ahead

When I worked at a large company, one of the things that stood out to me was the level of specialization everyone had. All my previous jobs were at smaller organizations where everyone had to know broader sets of skills often outside what might be considered their individual job description. A larger company allows for individuals to hone in on a specific area and become true "experts," and from that point of view, as any project moves through its development cycle, you'd ideally be handing it from expert to expert.

This approach has its pros and cons. It allows individuals to devote their time, energy, and learning to a very specific area to presumably become better at it, but it also means that they may not understand the implications their well-researched ideas may have on later stages of development. They may be torn between two ideas for a website interaction that seem equally valid, not realizing that one is a coding nightmare and the other is straightforward and simple code. In fact, when it came to web design, I would say that probably 70-80% of the people at the large company I worked at had no idea how to code.

As someone with a decently broad set of web knowledge, I worry that sometimes I suffer from the opposite problem -- I think so far ahead to the later coding stage about how I'm going to do something, that in the early design stages I may stop myself from creating certain designs because I know they'll be a coding headache, even if ultimately the overall experience/design might be better by going the more "difficult" path.

In the end, I think the best way to handle this is to try to focus on getting each step of the process right in itself, but with an idea in the back of your mind about how, for example, interaction may affect the visual design or how the visual design may affect the coding. Whether that is multiple people on one project or one person doing the whole thing, don't let yourself think TOO far ahead, but don't have blinders on either. It's a tricky feat of compartmentalization but, at the very least, it's worth taking a look at and being aware of how each step in your process affects the others.