Being the Bad Cop

It’s one thing to design something–but it’s often a huge struggle to implement it correctly. Wireframes and interaction designs are never enough. Good user experience designers have to be part of the entire development life-cycle–holding developers and the rest of the team accountable for detailed design, extensive user research, and expectations that have been set with stakeholders.

Being a good cop is pretty fun. For one, we’re known as the good guys because you never get into confrontations with people. Everybody likes us because we can make important promises and give users exactly what they need. Kicking off design is where most of us thrive because we love being around users, architecting solutions, and being creative. We always look good because we design based off of our extensive experience in human interaction and cognitive engineering.

It’s never fun when we have to be the bad guy. Being the bad cop happens frequently during and after implementation–when features are not fully developed to specification and it’s our job to call people out on it, ruffle a few feathers, and get things accomplished. Here are some important things we have to remember when being bad cop:

1. If we can’t prove it can be implemented, we really shouldn’t design it that way. The idea is to make something that insinuates the user experience, not something that is up-scope and over budgeted. Simple is okay sometimes. Some of the best interfaces out there are very easy to develop.
2. Be prepared to go behind someone and do it yourself. Not your job, role, or experience? Then you need to work with people you can trust. We should all try to build a skill set where we can play designer-developer if we have to.
3. Be practical. Remind everyone how the users will be effected or try to come up with a solution that is reasonable for everybody.
4. Monitor development regularly from start to finish. If implementation is over and design wasn’t followed to spec, it’s almost too late to make a difference without getting everyone around you frustrated.
5. Making arguments for the users are often not very popular on development projects. Sometimes, you have to make it sound like it was someone else’s idea in order for you to get them to buy in. If management is resistant to buying in, we need to remind them that it is our job to make them look good. User acceptance is a huge risk to the success of any software development product. If the user ain’t happy, ain’t nobody happy.
6. Be prepared to ask for a do-over. If it’s not right, it’s not right, but beware of scope–you can’t make a difference if you get fired.

If we’re going to be exceptional at what we do, we have to embrace the struggles and hardships of being bad cop. It may not make us popular, but it will certainly give us the reputation of being effective.