I’ve worked on a lot of different projects in my career, and I’ve learned quite a bit. I’ve always said 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 as well. I see a lot of UX articles that detail how to successfully execute a design project, but there’s not a lot of discussion on things to avoid. So, based on the mistakes I’ve encountered along the way, and conversations I have had with many of my peers, here’s some ideas on how NOT to do a design project.
The names have been changed to protect the innocent (and my ass).
Start from the “bottom-up” instead of from the “top-down”.
“Just do wireframes,” is what the project manager told me and my team on a high-profile effort, because that is all that we had “contractual obligations” to provide. No analysis phase, no design iterations – just go straight to detailed design. Well, that didn’t work, because we didn’t have a shared “vision” for the design team to follow… and we weren’t allowed to invest the time to develop one. A high-level design wasn’t something we “had” to deliver.
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 to what’s in the use case”… well, you’re setting yourself up for friction and potential failure.
Have no 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.
Have no conceptual or “high-level” design.
As stated above, you must have a direction that all the designers can align to and follow. It can be a set of best practices, a declaration of principles, a conceptual model of usage… But SOMETHING has to exist to ensure consistent and successful work.
Define 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 and without any flexibility you are going to end up in situation where quality is not a focus… crossing things off your list is. You have to be flexible and be willing to change plans as needed, based on revised requirements, test results, what-have-you.
Don’t let designers collaborate.
If you really want to fail, put designers on separate features and don’t let them talk to each other. 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.
Hire arrogant designers.
We all have various degrees of confidence in our abilities; we gain this confidence over time as we get 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 will alienate their colleagues and stakeholders and produce work that isn’t nearly as good as they think it is.
Don’t take any 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, put in your eight-hours and go home. That’s the wrong way to approach it. 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.
“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 who I can (safely) ignore. If you don’t have that clearly defined, then everyone’s opinion will “count” and it will turn into a painful a 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 them 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 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 too can experience a horrible design project. Good luck!