How (Not) To Manage A UX Project

I’ve worked on a lot of different projects in my career, and I’ve learned quite a bit. I’ve always said that I’d rather learn from someone else’s mistakes instead of my own, but I’ve had ample opportunity to learn from my own missteps too.

I see a lot of UX articles that detail how to successfully execute a design project, but I haven’t seen much discussion on things or steps to avoid.

So, based on mistakes I’ve encountered along the way (some mine, and some observed), as well as conversations I have had with some peers, here are some ideas on how not to manage a design project.

Note: Just to be clear, the following are things you SHOULD NOT do if you want a successful project. Trust me, I learned the hard way. Names have been changed to protect the innocent (and my ass).

Go Straight to Detailed Design

“Just do wireframes,” is what the project manager told my team and me on a high-profile effort, because that was all that we had a “contractual obligation” to provide. No analysis phase, no user research, no design iterations—just go straight to detailed design. Well, that didn’t work, because … well, we went straight to detailed design. We didn’t have a shared “vision” for the design team to follow … and we weren’t allowed to invest the time to create one. A high-level design wasn’t something we “had” to deliver, and the project went badly.

Treat Use Cases as Unquestionable Laws

I like use cases, I really do. I used to write lots of them. But when the use case explicitly directs the design direction (because the business analysts think it’s their “job” to do that) and the management team says, “design what’s in the use case” … well, you’re setting yourself up for conflict and potential failure. Why? Because use cases are usually focused more on business rules and logic and less on what the optimal experience should be for users. You need both, and blind adherence to use cases can result in the creation of a solution that may not align with what users want and need. And while business analysts are usually very bright and intelligent people, most of them aren’t user experience professionals.

Skip User Testing

This one is obviously a bad idea, but I’ve been surprised at how often the need for user testing has to be argued for, even in “savvy” user-centered organizations. Often user testing is cut because of budgetary constraints, or stakeholders say “why should we test, the design team knows what they are doing.” As good as your team is, design testing is far cheaper than designing in a bubble and then investing huge amount of money and time deploying an untested direction.

Don’t Create a “High-Level” Design

As stated above, you must have a direction that all the designers can align with and follow. It can be a set of best practices, a declaration of principles, or a conceptual model of usage, but SOMETHING has to exist to ensure consistent and successful work. Want your project to fail? Then don’t bother to do all this drudgery and work.

Use an Inflexible Design Process

I once worked with a project manager who was a “checklist” guy. Now, I love checklists, but if you follow your process/checklist blindly without any flexibility you are going to end up in situation where quality is not the focus, crossing things off a list is. You have to be flexible and be willing to change plans as needed, based on revised requirements, test results, or what-have-you. Unless you want to fail, of course.

Prevent Designers from Collaborating

If you really want to fail, put designers on separate features and don’t let them talk to one another. One major project started out doing exactly that, and the designers were also under tight deadlines. The result was a Frankenstein’s Monster of a design that was inconsistent and impossible to implement. Though, if this is your goal, congratulations! You did it!

"… if you want to fail, hire arrogant designers who think they know it all"

Hire Arrogant Designers

We all have various degrees of confidence in our abilities—confidence that builds over time as we gain more experience doing what we do. There’s confidence, and then there’s arrogance … and if you want to fail, hire arrogant designers who think they know it all. You will quickly discover that these people alienate their colleagues and stake-holders and produce work that isn’t nearly as good as they think it is.

Skirt Accountability

If you are on a design project that is use case driven, and the use case is the law of the land, it’s really tempting to just do what the use case says; to put in your eight-hours and go home. That’s the wrong way to approach design. The right way is to challenge the assumptions that are in the use cases and produce designs that aren’t “by the book.” Don’t give up, man up.

Never Ask: “Who’s In Charge Around Here?”

One of the first things I ask for is a RASI chart, a list of who is in charge and who the key stakeholders are. That way I will know whose opinions to heed and whose I can (safely) ignore. If you don’t have those roles clearly defined, then everyone’s opinion will “count” and it will turn into a painful design-by-committee situation.

Have a Super-Critical Stakeholder with Bad Communication Skills

If you want a design project to fail, then find the most critical person in your organization and make him or her the person who reviews and approves all the designs. Not only will he or she be negative but, because they have poor communication skills, they won’t tell you why they don’t like it. The result will be demoralized designers (and a revolving door they quickly leave through).

Have Meetings Without Agendas and Expected Outcomes

This is an obvious one, and is not just how not to do a design project, it’s how not to do any project. The larger the organization is, the more frequently useless meetings seem to pop into everyone’s calendar. A meeting without a purpose is a waste of time and money that can be better spent creating good designs.

Conclusion

There you have it, eleven ways you can ensure your design project ends badly. Or, you can avoid experiencing such a dire predicament by doing the opposite, and making sure that the project applies a thorough user-centered focus and follows a methodical process.

Good luck and please share any or your hard-earned “do nots” in the conmments!

Image of caution tape courtesy Shutterstock.