When I was a young Houstonian, learning algebra my freshman year at Elsik High school (cue the old jokes, or algebra jokes) I hated showing my work. I mean I loathed it! I thought showing my work was for chumps! I thought to myself, “I don’t need to do that, solving the problem and showing the answer is what’s important.” Uh, no. Wrrr-uuuh-ong! This article isn’t about high school math; it’s about showing your work as a UX designer. And if you’re stubborn, like me, and super-efficient, and a master problem solver, also like me, then you know this struggle.
What I want you to show
You should be showing the following deliverables, either, all or some in no particular order:
- Customer Journey maps
- User stories
- Ecosystem maps
- Competitive Analysis
- Value Propositions
- Results from stakeholder interviews
- Analytics/Data (measuring performance)
- Brainstorming (white boarding)
- User flows
- Use cases and scenarios
- Qualitative user research (process and results)
- Quantitative user research (process and results)
- Usability testing (process and results)
- Card sorting (process and results)
- A B Testing (process and results)
- Sketches (You probably thought this was all you needed to show. Wrong.)
- Pattern library
This is just a comprehensive list, not necessarily the list of deliverables you need for every project. Some projects may only require a few of these deliverables.
Did you see the words: “Final hero shot” anywhere on this list? Nope. You don’t need to show me that. It would be nice to show but I don't care about that. Just show me the steps you took to govern all the UX. Tell a story. Tell your story. Don't be overwhelmed. You do this, every day; now you just need to document it.
"Just show me the steps you took to govern all the UX. Tell a story. Tell your story."
Why you don't like to show it
The problem with super smart, high performers, is that you think the world bows at your feet. Now, you can deny this up and down until the cows ???????????? ???? come home, but let’s face it, you’re an ass. There’s an ego that comes with intelligence, and your iceberg took out the titanic. Drop the ego and start being respectful. Part of being respectful, is disseminating the UX details and documents, to your team.
"You need to document these processes and show them to your team."
You like solving problems don’t you? You like to show off and say things like “That customer journey map is easy to make, I can knock it out in an hour.” Well, great! Now you’re starting to see that, the biggest enemy here, is you. You may know the entire process, and you may totally understand how you got there, but that doesn’t put you in a position to be able to eloquently communicate that to: your team, stakeholders, execs, or your clients. You need to document these processes and show them to your team.
The issue is, you think it’s okay to not show your work, because you’re so badass and you feel you don’t have to answer to anyone. Not true. You’re obligated, as a User Experience Professional, to constantly communicate the product’s vision and design direction. This isn’t rudimentary high school math, at an over populated urban school — this is your job! Take it seriously and show your damn work!
"You’re obligated, as a UX Professional, to constantly communicate the product’s vision"
What, not showing your work, says about you
Do you want a high paying job in a super competitive field with perks, bonuses, vacations and an ultra-rewarding end-result of enhancing the lives of millions of users? Do you want to work with smart people who strive for the best? Do you want to be surrounded by a culture of excellence and be rewarded, and recognized for your efforts? Of course you do.
Do you know what not showing your work says about you? Not showing your work is the career equivalent of saying: “I want a low paying job, as a dirtbag designer, with no extras, because I’m a mediocre cheese muffin. It also says, none of the critical parts of the UX process, were tools I have any experience in using. Wow! Is that who you are? Is that what you want to be? No. So show your damn work!
"Not showing your work is the career equivalent of saying: I want a low paying job..."
The real reasons why you don’t show your work
Okay so if you’re already drumming up excuses, stop reading this. This article isn’t for wimps. This article is about tough love, and I only want to impart my wisdom to those who are worthy. If you call yourself a user experience professional and you’re still coming up with excuses, allow me to revoke that title from you. There are no excuses anymore. This is reality. To be better, you need objectivity and truth. So the truth can be either of the following:
- You're lazy.
- You don’t know how to make these documents, or how to show your work.
- Your current role doesn’t require it.
"If you were a hiring manager, would you want to hire someone who’s lazy?"
If you’re lazy, okay. We can work with this. The key here is to start bundling in these deliverables into your process. That means the next time you start a project add them into your process. And by-the-way, If you were a hiring manager, would you want to hire someone who’s lazy? Think about that for a second while you let your cheerios soak.
When you start working on a new project ask yourself how you can incorporate these deliverables and begin to use them with every project, going forward. If you’re worried about it taking too long, decrease the fidelity. I want you to show me an information architecture map, even if it’s a quick sketch on a whiteboard, it’s still a freaking information architecture map. Take a picture of it with your rose gold iPhone 6S plus, add it to a PowerPoint deck. Shoot it off in HipChat or Slack to your buds. Done.
If you don’t know how to create these documents and deliverables, that’s okay too. Take a look at the links above. Read. Read some more. Learn. Read, and repeat. Not a big reader? Try immersion. Patrick Neeman, is a great guy to follow on Twitter or even Ha. They will proliferate some great resources that will help you progress and go learn your craft. If all else fails sit in a design session with David Sciacero. He’ll fix you right up.
"Find people who have done this before. Find people who have done it successfully, time-and-time again."
DISCLAIMER: I don’t want to imply that David is offering sessions, but he’s the best of the best in the industry. Follow him on Twitter and he may throw you a UX bone, or two, every now and then, or talk about something cool like curling or something.
My point is, find people who have done this before. Find people who have done it successfully, time-and-time again.
If your current role doesn't require this, you might not be a UX designer. Yeah, there’s that. So you may need to proactively deliver these documents, anyhow. If they’re well received, bravo. If not, look for a role that allows you to use these skills, daily.
"Showing your work is more simple than you think."
How to do it?
Showing your work is more simple than you think. You may be feeling a little indifferent about it right now because it can sound daunting. Not true. When you start any project you have a discovery phase. During that phase take a look at the 24 deliverables above and plan out your own roadmap. Break down what you plan to do. If you use Jira, make each of these a subtask in Jira. Then build them out.
I love knocking things out fast! If you’re like me, you shine when you execute. I personally like to use vector tools, because I can throw my work up quickly and ship it as a PDF. Then I can update and iterate quickly when needed.
Creating a Story
Now put all of these deliverables together. It doesn't have to be all at once. Take it day by day. Piecemeal. Sort of like a journal. I usually save a master folder on my desktop and break out folders within it. This is where I categorize my deliverables and keep them nicely organized. When you’re finished you can go back and look at what you’ve done, in amazement.
"If you can do the work you can catalog, and document it."
I also keep any photos I have taken during the process. Along with any notes. If you get praises and accolades along the way, write them down. They show that your work was validated.
In the end, you should be able to put together a beautiful story. This story will show peaks and valleys; it should have a climax. You should be able to show the pitfalls you encountered, the problems and constraints you ran up against. How you dealt with them. What you did to alleviate them. The impact you had when the product was in the hands of real users.
If you can do the work you can catalog, and document it. I remember, the worse part of college, for me, was paying for tuition and signing up for classes the next semester. Man, I hated that. That’s what showing your work feels like. It’s feels like an arbitrary admin task that’s beneath you. Not true. The trick is to make it a part of your process. Incorporate it early and live by the process.
"The trick is to make it a part of your process. Incorporate it early and live by the process."
I wish you the best in all of your endeavors! Remember to catalog, and document daily. Even if it’s just scribbling in your moleskin or creating a folder with a couple of PDF’s.