Why would you settle for less?

When migrating to UX, why do people stop pursuing self-betterment in terms of design craft and polish? Why do UX designers not invest more time and energy in improving their visual skills? How can that hurt them?

When challenged with questions like these, UXers are quick to defend the reasons why higher-fidelity deliverables is not a priority for them.

“I would rather focus my time on learning user-centered design methods such as research and strategy.”

Sure. How much time have you spent last week studying new research and strategy methods? Chances are you haven’t. We are pretty good at making excuses for ourselves. Also, once you learn how to operate the more strategic design tools (e.g. moderating a focus group, or mapping the user’s journey), improving on it is more of a matter of practice than dedicating additional time to study how that’s done.

Once you learn to be strategic, you rarely un-learn it.

“But I‘m too busy and I can’t spend too much time refining a deliverable that will be used for internal purposes only.”

So how about becoming faster at producing polished designs? You are only spending 8 long hours polishing the visuals of that user journey because you lack practice. When you get over the hump and become more trained at observing and fixing tiny design inconsistencies, you will get faster and more efficient at creating deliverables that are better looking and easier on the eye.

“But I want to keep it low fidelity to gather the right type of feedback from users.”

The higher the fidelity, the more specific is the feedback you’ll get. Fact. The whole reason why we seek user feedback is so we can use the insights gained to further refine and improve our designs — so the product shouldn’t be fully finished for user testing sessions. Here’s a quite well articulated counter-argument by Arin Bhowmick: “However, you might also have heard people tell you that if you’re wanting to test how someone will respond in a specific scenario, the closer the ‘test’ or ‘model’ corresponds to the reality that it is simulating, the more confident you can be that their behavior in the test scenario will be truly representative of how they would react in the real scenario.” The answer, according to Bhowmick and the way they work at IBM, is pretty powerful: “Seek feedback on your lo-fi explorations, your hi-fi prototypes, and everything in between.”

“But no user is going to see this journey map.”

Your coworkers will. Your stakeholders will. There is even a chance this journey map will be circulated across the entire organization, becoming the bible to how your company understands the user’s journey for years to come. It’s your name and your legacy behind that document — isn’t that enough of a good reason to invest more time into making it look better?

So why would you settle for less?