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.


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.


"Meetings Without Agendas and Expected Outcomes" - such an easy way to waste time and blow every project. Everyone knows that and too many still don't put that knowledge into practice.

Seriously, do you work at my company? :-P

That first one...

I was once on a project, listening to the direction a company wanted to go and who their users were, started digging in asking questions, and someone responded, "I'm sorry, but why are you - you asking these questions? It's not your concern."

Uhm... how is one to see the big picture, to create a unified and usable solution, without enough information? Plus there are occasions where these questions, the uncomfortable ones, have to brought up early and often so clients aren't surprised when they have to deliver "stuff" to move the project forward.

Yeah... I just produce wireframes and do sanity checks. *looks to the sky*

Hi Joe,

I couldn't agree more, BA not only thinks that directing design is their job but they also strongly believes (some of them) that designing wireframe also part of their job and UX = Graphics is their ultimate understanding....

It's a shame that so many BAs think that way but many do. It makes me wonder how they look at other aspects of the business. Now, I've had some BA/IA roles where I was writing use cases and designing user flows but even then I would never, ever spend time creating wireframes. This is not to say that I wasn't presenting my ideas and concerns during our brainstorming sessions or in the design reviews. Of course I was but I was careful not to step on any toes.

It would be as if the IA thought he was a Creative Director and spent valuable time working on fonts and graphic design.

Hi, I like your article... Thanks for the tips!

Great. You have just about described my daily life at work, Joseph :) Not only most of it is true, trying to improve the bad environment we UX designer have to work in (vacuum) bc of total lack of understanding of what we do is one of my biggest frustrations. Most of the people on the team I work with day-to-day don't even have the slightest concept of what I'm talking about whern I bring up some of these issues. So, it's not the issues themselves that are the problem so much (even though they are), but the people in charge who need to be educated about these issues. Until we bridge that gap somehow I don't see a solution. I'm talking Chinese in Mecca.

Regarding your point about treating use cases as unquestionable laws: We don't always have any influence over the work of Business Analysts, but I've always advocated for omitting any description of interface components from use cases, unless the interface already exists. Describing the UI before it's been created clouds the information that the use case is meant to provide, often leaving the actual rules, actions, and requirements that the use case is meant to provide lacking in critical detail.

Nice article.

I would also like to know, how i can ask my seniors to let me collaborate with others or involve design opinion during use case creation.
I recently created a presentation on the design process to be followed so that the mangers are aware of the appropriate method.
Is there any other ethical way?

Great article. Too many of us have seen every one of these in action.

Great Article.

Great points. I'd also add:

-Set a launch date and set that in stone, even if key features/functionality are not ready.
-Don't work or collaborate with other key stakeholders (SEO, Technology)

"Treat Use Cases as Unquestionable Laws" is so common. So often a story with have a definition of page and not a user story at all. Very frustrating.