A Team & Project Blueprint for Crafting Great Web Experiences

Designing a usable, valuable, simple experience for the web is hard. But if you know what your team and project needs are right from the beginning, you can make informed decisions about how to handle any situation you are presented with.

Read more articles on Design, Process

Before we jump into what makes up a great experience, I think we have to define what a great experience is, which is a rather lofty goal in of itself. We know what attributes great user experiences have:

  • they are easy to use,
  • they’re fast,
  • they give me what I need when I need it,
  • they’re predictive of what I need or how I plan to use it,
  • it solves a problem I either knew about or maybe I didn’t and it wasn’t apparent until I had it in front of me.
  • and the list goes on. I’m sure you can define it better than I can.

It all sounds fine and dandy, but creating a meaningful and valuable solution for someone other than yourself is extremely difficult and can only be accomplished by having the rights qualities within your team and following a few key mantras for your project. First we’ll talk through the team qualities that are needed.

Team needs

Lose the egos and ground your team in empathy

Websites and applications that provide great experiences are not advertisements. This is not something you impose your whimsical, genius, mad men brush strokes to and sit back and watch the users flock to the beautiful design.

This is something that someone else is going to have to use. You can do everything below in the this post, but if you have a ‘genius’ on your team, you’ll be constantly trying to defend the process instead of focusing on the collaborative work that is needed.

I’ve seen it many times. A Creative Director, with a capital “C” and capital “D”, tells me “we’re spending too much time “up-front” and we need to just “create” to win that elusive “award.” Without talking to a user or understanding the content, they jumped right into Photoshop to create. After spending a couple hundred billable hours, they hand their creation off to a developer who has a million questions about everything the CD didn’t think through, they release something based on a deadline that was set months ago and never addressed after, and voila, the creation is created. And you can rest assured they created alright, they created a pile of crap that users will struggle with and ultimately abandon, costing the company potential millions of dollars in lost revenue, employee or consumer productivity, increased help desk support, etc.

If you ground your team in empathy, it means talking with users and understanding their needs and problems, investing that extra time up front in order to ensure quality and value. Once we can see the problems through the lens of the humans we are designing for, we can start making informed design decisions through evolutive and iterative design cycles to vet out the qualitative and quantitative improvements. You have the opportunity to talk with users, ask them what they’re needs are and start from there.

Lose the ego.

Collaborate with everyone and stop being a controlling jerk

Collaborative design is about working with others. Easy, right? But what tends to happen, is what we call collaborative designs ends up meaning, “I’m going to sit in my office for a few days, and show you what I have cooked up so we can iterate on the first thing that popped in my head and you probably should think twice about changing it or providing your feedback, because I will vehemently defend any changes to my work of ART.”

This is not collaborative, it’s controlling and not productive at all.

Will Evans (@semanticwill), Russ Unger (@russu), and Todd Zaki Warfel (@zakiwarfel), not really sure who made it up or who adapted it first, but they promote and talk about a collaborative design method that includes a multi-disciplinary team, from stakeholders to developers and every team member in between called the “6-8-5 Design Workshop.” 6-8-5 stands for producing 6-8 sketches in 5 minutes and is a wonderful to get all team members producing a lot of ideas, in a short amount of time. The designs then are presented and critiqued to allow for the discussion to take place amongst various personalities to allow for a more collaborative, divergent process to take place early in the project timeline. I have found this to be a wonderful exercise to remove ownership of a limited amount of ideas and gain buy-in from stakeholders right from the beginning.

More collaboration and less controlling designers working in silos.

Know the strengths & limitations of your teammates

It’s like going to work, but not going to work. More like, going to hang out with friends … while you organize content and sketch all day or smoothly code up a UI transition that makes your hair stand up on your neck. Then you finish up your day happy as a clam, maybe hit up a happy hour with your coworkers that made the design you were working on even better from their constructive input.

Ahhh, the perfect job! The perfect team balance. It feels more like hanging out with friends while doing what you were put on this earth for.

Then you wake up and realize everyone, from the account management to the project managers to the designers you are working with are all just learning this web thing and you realize this project will probably get misguided in various directions. Your client’s expectations won’t be properly set, ambitious designers will start “designing for design’s sake” and before you know it, boom, the project blows up in your face.

As you look at your watch every hour and half to see how much time you have until 5pm when you’ll try to get to the door without being noticed, you realize, this is not the optimal team balance I had in my dream. Even better, you think about the team’s you previously worked with and start analyzing their make-up and comparing to the present situation. It’s only natural to judge what’s in front of you and compare to previous experience.

You realize, while it may not have been the ideal situation, but the team you worked with a few years back actually was a pretty decent make-up of experience and discipline strengths. At that moment, you know exactly what you’re looking for in a team you work with.

Take time to learn your teammates and your own strengths and weaknesses. If everyone can talk about and accept how the team works together and who’s responsible for which aspects of the process, that’s when the walls are broken down and true collaboration happens. Everyone has a role. Everyone has a specialty or two, and knows what’s expected of them and that there’s no underlying feelings getting hurt that never get talked about, which could pull a team apart.

Project needs

Know the problem you’re trying to solve

A client or product owner say something like “We need an Android app!” And your natural problem solving gears get into motion. You say “This person needs an app, and I’m an expert designer! Cool, I really wanted to work on an Android app that does something like this! Challenge accepted!” Maybe you follow a user-centered and informed process, or maybe you’re a creative director genius like above, either way, you go about your design process, develop it, ship it and booya, you’ve created your Android app. Problem solved, file it in my portfolio as something I can do for future clients.

Whoa, kemosabe. Pump your brakes, champ.

Did you follow up with that project after you released it, better yet, after “your” design phase was complete? Do I dare ask, did the stakeholder? Or did everyone move on to the next big initiative/project?

Let me tell a little story of why it’s important to understand the problem you’re trying to solve and validating that it is a viable problem to solve.

I worked on a project, briefly, before the big shot designers got involved and wanted to take over the project that went exactly how I was describing above. Project came in, client said it needs to do something without really understanding viability of what they were doing, designers took over, we developed it, released it and it fell flat on it’s face. No one used it and the one’s that did, mostly were from the project team just testing it, thought it was incredibly difficult to use and hardly saw value of it. But $500k later, they had their app. But the astounding thing about it was, that the people I observed having trouble with it, the uber designers, said it was awesome, and a great success. At the time, I thought to myself, “Are you f-ing crazy? You are aren’t you, you’re delirious. Either that or you’re drinking your own Kool-Aide, Kool-Aide spiked with LSD.” I think the designer saw it in my eyes and said, “I think we’re going to win an award with this one.”

Welp, on to the next project.

Okay, maybe I’m being a little too critical. Besides, a lot of projects/start-ups fail, right? You never know until you throw yourself in the ring, right?

But maybe we should be a little more critical, skeptical, about the projects we take on and the process we follow. Where do we set our own expectations on quality? Maybe we need to take a deeper look at the motivations for what problems our friendly clients/product owners are trying to solve before starting up the design machine.

To do our due diligence in this area is really easy, act like a 4-year old. Ask why to every answer the client/product owner gives you an answer to, until it uncovers itself.

You need an app, huh? Why? Oh, only because you saw a cool app on your own Android device that you could find budget for, well guess what dude, all of you potential users for this particular audience for this app you need, don’t need it and by some outside chance they do, they all have feature “flip” phones. I would love to take your money, but good thing we talked this out, right?

Know your content

Knowing the content you’re designing with is just as important as knowing the problem you’re trying to solve. The more intimately you know your content, the easier it will be to make decisions about how to design for it, how to guide your client on how to update it, who updates it, how to develop for it, and so much more.

I’m just scratching the surface with this section, but the whole Information Architecture, and subsequent Content Strategy, thing is much more than nerds who don’t understand how creative direction works spewing a few quotes from books that have animals on the covers. It actually makes designing easier, mitigates timing/costs risk to the design/development process and provides a roadmap for the life of the content.

Knowing your content is just as important as knowing your users. Period. Put down the Lorem Ipsum, Art Directors. Read a book about IA (Information Architecture for the Web) or the design process in general (Rosenfeld Media Books), read good articles on designing for the web (BoxesandArrows.com or AListApart.com), or attend a conference (IA Summit) and learn from those who really know how to approach content and design on the web.

Know your users

Talking with users, understanding their motivations, desires, emotions and cognitive abilities is a must have when you’re designing an experience that other people have to interact with and use.

Who are the people we are designing for? What is the activity (or activities) they are trying to perform? How might users think about performing these activities? What are the contexts in which they are trying to operate? What frustrates the people you’re designing for? How much wood would a woodchuck chuck if a woodchuck could chuck wood?

Answering each of these questions will undoubtably leave you with a empathetic viewpoint of who you’re designing for. If answering them doesn’t make you feel empathy, you’re probably a cyborg. In which case, you should probably be partying with Data from Star trek instead of designing interfaces. Your team needs to be grounded in empathy in order to think about the problems you’re solving from a different lens, and actually remove your own ownership ego from the equation.

Let’s make sure that we’re actually solving a problem instead of creating five new problems.

Evaluate & Iterate

Great, you’ve gotten this far. You know and trust your teammates capabilities, understand front and back the problem you’re solve, who you’re solving for and how they intend to use the content you know like you majored it in college.

But when you put dry-erase to whiteboard, or boxes in Omnigraffle, or pixel in Photoshop, or inline CSS to HTML (just kidding, you semantic freaks), you still are making big assumptions that your concept will match your users mental model, or their expectations of what will work easily.

Now we separate the women from the girls, the men from the boys, the humans from the cyborgs.

That’s right kids, we need to perform some usability testing on this beast of a design. We need to evaluate the design, quantify the value of this new design or design change against our previously measured metrics. Does it work better? How much better? Is there anything we can do differently in the design before we choose to develop this change?

Evaluating and iterating the design, not only will help ensure you’re delivery a sound product, but also give the business a measurable return on their initial investment on this project.

Now is the time you can put this project in your portfolio with the headline “This design saved the client $11 million over 3 years, want to know more how I can help with your project?”