Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Business Value and ROI ›› 6 Key Questions to Guide International UX Research ›› How (Not) To Manage A UX Project

How (Not) To Manage A UX Project

by Joseph Dickerson
5 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

He learned the hard way so you don’t have to: how not to manage a user experience design 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.

post authorJoseph Dickerson

Joseph Dickerson, Joseph Dickerson is a writer, technologist, and user experience lead who specializes in "next-gen" experiences and products. A designer of multiple mobile and Internet applications, he has worked to make technology easier and better fo users for over a decade. The author of several books, including a primer on user experience design, Experience Matters, Dickerson is a regular contributor to many websites as well as editor of This Week in UX, This Week in Geek and The Twin Peaks Gazette. He recently completed his second book on UX, UX 101.

Tweet
Share
Post
Share
Email
Print

Related Articles

How UX teams can provide key insights using technology adoption models

Article by Lawton Pybus
What Makes Users Adopt a New Feature or Tool?
  • The article explores the evolution of technology adoption theories, focusing on models like Diffusion of Innovations, TAM, TAM 2 and 3, UTAUT, and HMSAM, providing UX practitioners with tools to understand and enhance user behavior in product development.
Share:What Makes Users Adopt a New Feature or Tool?
6 min read

What do Architecture, Computer Science, Agile, and Design Systems have in common?

Article by Kevin Muldoon
A Pattern Language
  • The article explores Christopher Alexander’s impact on diverse fields, from architecture to software development, introducing the concept of design patterns and their influence on methodologies like Agile and the evolution of Design Systems.
Share:A Pattern Language
7 min read
Article by Eleanor Hecks
8 Key Metrics to Measure and Analyze in UX Research
  • The article outlines eight essential metrics for effective UX research, ranging from time on page to social media saturation
  • The author emphasizes the significance of these metrics in enhancing user experience and boosting brand growth.

Share:8 Key Metrics to Measure and Analyze in UX Research
6 min read

Did you know UX Magazine hosts the most popular podcast about conversational AI?

Listen to Invisible Machines

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and