Surveying the UX Portfolio Advice Landscape

One of the first things I did, after determining that UX portfolios were apparently a thing, was to fire up ye olde Google and type “UX portfolio how to”.

There are many, many, many UX portfolio articles, presentations, recaps, and templates (for purchase, natch) out there. There is even, someday, going to be a book, but it’s overdue, and now estimated by Amazon to be published in Q1 2018. At first blush, it seemed odd: surely there can’t be that much disagreement on what constitutes a UX portfolio, right?

Au contraire, mon ami.

Come with me on a wondrous journey into the evidence-free zone of homegrown wisdom, personal bias, and rhetorical fallacies as far as the eye can see!

(I’ll list the bibliography of articles and presentations at the end of this post. I do not claim this list is exhaustive, nor complete, nor even the best quality. I claim only that these were the most referenced, and linked, via Google and Twitter.)

Ipse Dixit, Nullius in Verba, and Hitchens’ Razor

First, a digression in Latin, because I am a Classics nerd.

In classical rhetoric, there is a fallacy known as ipse dixit, which is translated as “he himself said it”. Ipse is an intensive noun, nominative singular -- which means it’s the subject of the sentence. The use of ipse rather than the reflexive ‘se’ is indicative of the seriousness with which the emphasis needs to be considered.

Dixit is 3rd person perfect tense of the verb for “to say/to speak”: he said. Perfect is a past tense which indicates actions that took place non-repetitively in the past (as opposed to the imperfect, which is for ongoing actions in the past).

'Having said it once is all the proof or evidence that is needed': this is the essence of the ipse dixit fallacy. The very act of the statement is the proof.

Nullius In Verba is as close to a personal motto as I’m comfortable with, and serves as the counterpoint to ipse dixit. The motto of the Royal Society, it means “on the word of no one”. In Buddhism, it’s the teaching that one should never believe what one cannot experience independently.

Finally, we have Hitchens’ Razor, named after the late writer and intellectual, Christopher Hitchens: “That which can be asserted without evidence can be dismissed without evidence.”

I think you can see where I’m headed.

So, Why Do You Need a UX Portfolio?

You need a UX portfolio because you need a UX portfolio.

The End.

And while such spurious logic is enough to rationalize the existence of dozens of related how-to articles, it gets us no closer to understanding why a collection of research, strategy, and site architecture is at all appropriate for the portfolio format, nor why it’s a fairly recent development.

“Portfolios are very important” (3) claims one recruiter interviewed by Usabilty Geek, in an article which takes such pronouncements at face value, though the recruiter does mention that a portfolio provides “support” for all of the experience listed in the resume. Here, the curtain pulls back a bit and you begin to suspect that, perhaps, there’s a lot of deception at play in UX candidate land.

“Possessing a portfolio demonstrates credibility”. . . . “A portfolio demonstrates that you are committed to your craft” (7)

If tautology and ipse dixit had a baby, these statements would be it. The only thing that a portfolio demonstrates is that you have a portfolio.

“In 2014, if you are without a portfolio that showcases your UX thinking and execution, you will be extremely lucky to be invited in for an interview. Moreover, it is no longer acceptable to simply show final output that provides little or no context about the design challenge and the thinking process in addition to what’s been delivered.” (1)

Do you notice the glaring absence of the “because” clause in that paragraph? There is no reason why anyone should read that series of words and not think, “Hey, hold the phone -- WHY??”. The author is drawing some fairly serious lines with “no longer acceptable” and “simply show”. Those aren’t mincing words.

“Employers and recruiters use UX portfolios to determine a candidate’s experience, seriousness and, most importantly, ability to successfully follow UX best practices and processes.” (8)

Oh boy, where do I begin with this one? While I will punt on the issue of “experience” and the ability to gage it from a portfolio, I must take to task the notion that anyone’s level of “seriousness” can be, and more importantly, should be judged by a document. Again, we see a wholesale reluctance to speak to candidates presented as fait accompli. Still, we are left to wonder: by what criteria is a candidate’s seriousness to be judged? “The judge from Finland awards this portfolio a 6.5 for seriousness, but the judge from Laos awards 7.2.”

The bulk of my ire, however, is reserved for “successfully follow UX best practices and processes”. There is no such thing as UX best practice(s). Period. Full-stop. End of story. That this myth persists is the perpetual thorn in my side. I can only assume that the work that UX professionals do is so confusing, that outsiders console themselves with a belief in a Best Practices handbook.

And, as anyone who has been around the block can tell you, no one who uses “best practices” in conversation can tell you what they think they are. This would strongly suggest that what a hiring manager at Ace Digital Agency thinks is a “best practice” is entirely different than what a hiring manager at Hopper Huge Corporation thinks is a “best practice”.

Another article claims that the purpose of the UX portfolio is to demonstrate “skills and talent, personality, accomplishments, evidence of work that can be reviewed and compared to other designers’ work.” (2) With exception of the last reason (in and of itself enough to chill the bone), one would think that at least some of those points could be achieved more readily by a thorough read of a resume, in addition to a phone call or interview.

But we’re already in a land where practitioners have all but given up hope of ever actually meeting a hiring manager if one’s personality is meant to be conveyed via portfolio. The article goes on to assert that a portfolio must always begin with a personal introduction; of course, because meeting people is simply beyond the pale.

Better Call Saul, Because This Legal Advice Is Horrible

In terms of intellectual property law, a copy of a thing is indistinguishable from the thing itself. If you recreate, in totality, a Tesla, but you call it a “Zippy Zoom Zoom”, you’re still in the wrong.

With few exceptions, UX professionals who work for agencies, firms, and corporations sign contract and NDAs that are classified as “work for hire” which transfers, automatically, ownership rights of that work to the employer. So, in effect, you did not create those wireframes, friend: Ace Digital Agency did.

So when I read, repeatedly, advice to “recreate” work covered by NDA in order to put it in a portfolio, I am shocked, disappointed, and frustrated.

These pieces of advice are all legally wrong:

“Blur sensitive info” (if you’re under NDA, it’s all considered sensitive info)

“Create sample of your work” (recreating IP is still IP)

“Use text only version of your work” (2) (A sea of lorem ipsum!)

Please don’t do this. Please. If you have work that you cannot legally share (and brass tacks, you aren’t even supposed to retain a copy, another issue that UX portfolio advice articles seem oblivious to), then either a) write about it without naming the client, and don’t show images at all; b) show it only during in person interviews, on your computer, and then immediately wipe the memory of your interviewers.

When the articles surveyed managed to mention NDAs, they all tended to agree: you don’t share NDA work online, over email, etc., but you can usually show it in person, with no leave behinds.

You Must Have Case Studies (That No One Is Actually Going to Read)!

You’ve gotta tell a story! About the work! So you should have case studies! Yeah!

Case studies, by definition, are not short. You’ve got to set the scene, provide background, introduce the dramatis personae, and explain what you did/what went wrong/what went right/, etc.

You are not going to do this, adequately, in under 500 words.

But wait, there’s even better news! If you’ve got 3-5 case studies, that’s 3000+ words, requiring at least 30 minutes of someone’s time.

No one is spending more than a few minutes--if that--looking at your portfolio, kitten. I’m sorry. In the articles surveyed for this blog post, estimates ranged from 30 seconds, to 3-4 minutes (but only in round two!).

So, you know what that means: LOTS OF PRETTY IMAGES TO CATCH THE EYE!

Light In the Darkness: You Oughta Write, Kid!

“Nine times out of ten, when people contact to express interest in working together, they don’t say, “I love that screenshot in your UX portfolio” or “That user-flow was really awesome.”

Nope. Instead, they say things such as “I read that blog post about …” or “I loved that article that you wrote for ….” People connect with how you think, with your thoughts, ideas, and observations. People will only be able to make that connection if you take the first step and just start writing.” (5)

Sarah Doody emerges as the one sane, practical voice in the UX Portfolio advice wilderness. At the heart of what we do, professionally, is the ability to explain, to reason, to communicate. If you cannot write clearly and persuasively, then you cannot successfully do user experience work. The ability to write well is tied directly to the ability to think well. Bad thinkers are bad writers, and vice versa. (Of which one can find ample examples in the current political realm. Ahem.)


That’s a solid, and fair, point. I would posit one of two things:

  1. The people who don’t spend much time reading portfolios will, probably, not spend a lot of time reading blog posts. But that, to me, is a bit of a red flag. When it comes to work, I don’t trust people who don’t read, because I think it speaks to an extreme laziness of mind, and indicates a poor fit on both sides. See also: Bill Hicks and the Waffle House waitress.

  2. The people who review portfolios may not spend much time reading portfolios per se, but may enjoy reading blogs and articles that cover their profession.

Ultimately, however, writing is more about the benefits to you, personally, than to an audience. Writing is brutal, brain exhausting work when done consistently. It’s also extremely rewarding, as you watch your thoughts form, and change, and crystallize in black and white. It keeps the mind limber, and that’s always good.

The more you write, the more you think; the more you think, the better at thinking you get. Practice!

If you need additional convincing on the power of writing to improve thinking (and vice versa), I direct you to Writing Down the Bones by Natalie Goldberg; On Writing by Stephen King; Letters to a Young Contrarian by Christopher Hitchens; anything by Richard Fenyman, and Politics and the English Language by George Orwell.

Something Rotten In the State of Denmark

UX hiring has taken a turn into the absurd. There are endless excuses for it, none of which I find compelling, nor worth serious consideration. I think, ultimately, that people are busy, and busyness induces laziness, and all of that while trying to operate in labyrinthine corporate hiring processes is a recipe for the crap situation we have now.

But this is no different than what we face on any project! Who among us has not walked into a stakeholder kickoff meeting, and emerged slackjawed at the work in front of us, seemingly insurmountable? What is missing, ironically, is the same thoughtfulness of approach that UX professionals would take to any research project.

Publication Note

Sarah Doody has begun offering a UX portfolio school/training class. Work and life have colluded to prevent me from sampling this offering. Given the referenced blog post by Doody on the importance of writing, this latest development is unfortunate, and yet, we all must pay the bills.



UX Portfolios & Me: Some Context Setting

Before I dive into a series of blog posts examining the current state of UX portfolios (the whys, the hows, the WTFs), I think it's best if I provide some context around why I even want to investigate.

I Went to Scrum Land and All I Got Was This Backlog

In September 2014, I took a contract position as a Product Owner at a local educational software company. I was intrigued by the position for a number of reasons:

  1. The PO role combined everything I had learned in my career to that point: UX, business analysis, project management, leadership.
  2. The company was using Scrum, and I hadn't ever had a chance to truly work in a non-waterfall environment.
  3. I liked, and had worked with, the woman leading the PO/UX/BA group at the company.
  4. It seemed like a HUGE challenge, and I was ready to do more than being a freelance wireframe monkey.

In the space of about 2 weeks into the gig, I devoured every book on Scrum, Agile, and Product Ownership that I could. About 2-3 weeks after that, I was asked if I wanted to come on full-time. I demurred, because I still felt like the water was exactly at my head. It was an exhilarating kind of scared: I was out of my depth in terms of having to figure things on the fly, and thus had to work hard not to miss things, but I had all the skills and experience I needed to manage the chaos.

Around November, I felt like I finally had a handle on things, the water had receded to mid-chest level, and I said, "Yes, I'd like to join the full-time staff." That went through in January 2015, and with that, I ended 6 years of very successful independent contracting.

There was good, there was bad, there were great successes, and frustrating failures. Long, complex story short, I came to a crossroads, and decided to resign in June 2016. 

I liked Product Ownership—it felt like where UX ought to be headed, long-term: getting us out of the deliverable business, and back into the strategy and vision work. However, PO roles in Chicago tilted heavily toward demands for dev/programming chops, which I just do not have, so back to UX I went.

Man, I leave UX proper for 18 months and y'all lost your minds! (I kid, I kid—sort of.)

At some point, hiring managers stopped wanting to talk to people.

When I left Critical Mass to go freelance in October 2008, it was (obviously) a different world. It was the time before bootcamps, when we were still (still!) trying to get companies to budget for sitemaps, and wireframes, and (please please) usability testing.

By April 2009, I stopped even having to interview for gigs: instead, I got calls and emails, asking when I was available, and what my rate was. My biggest challenge at the time was negotiating rate, and having the courage to name a rate, and stick by it. Calls were centered on understanding the project, hashing out timelines, discussing the client and team. 

My CV stood on its own: the agencies and clients I had experience with, the people I'd worked with, as well as (at that time) 9 years of experience was evidence that I could deliver. And, never once did anyone ask me to complete a 'design exercise'.

Was I asked to show previous work? Yes, sometimesbut always during an actual in-person interview. I was never asked to provide samples before someone would even decide whether to talk to me. Once in the interview, I would show work, and provide the story behind the project, and my role in it. I'm an ace storyteller, and it was both fun, and exhausting. I even spoke about this for an article in UX Matters in 2009, back when we were lamenting the beginnings of a focus on output over methods.

Imagine, then, the shock that ensued when, now with 16 years experience and a much longer client list, I was repeatedly asked for a portfolio before anyone would even consider talking to me in person.

I thought I was having a stroke. (I kid, I kid—sort of.)

Are they even looking at my CV, I inquired? (Because it's not short on detail, that CV, and there's an even longer version.) Yes, would come the response from the recruiter, but they want to know your process. Well, I asked, what on earth will we talk about in the interview?

It was a topsy-turvy world that I didn't understand. I heard over and over again that companies wanted to understand my 'process'.

My process? My interior monologue at the time was: Well, I work for agencies and consultancies, so they have established processes, and it depends on what the engagement is, we may not get to do all 4/5/6 phases, it could just be discovery, what the hell do they think 'process' means? Do they think I get to pick my own way of working? Why would they think that? 

(I came to understand that the question is meant to get at whether I know that it's good to interview users, and stakeholders, and gather requirements, and collaborate with a team, et cetera. I'm shocked that there is a subset of people who apparently don't know these things, but here we are. 'We want to understand your process' = 'We want to make sure you actually know how to do all the parts of your job'.)

The single biggest shift has been what certainly appears to be a deep-seated reluctance to meet candidates in person, and do the conversational legwork required to evaluate them for a role. Instead, send a portfolio which will reveal all your professional facets to a hiring manager for a speedy review! 

Utterly bizarre.

I started interviewing recruiters and hiring managers, trying to understand this weird hiring world I was re-entering. And it, more or less, boiled down to two things:

  1. UX had succeeded beyond its wildest hopes, so everyone was saying they 'did UX' on their CV, whether they had or not;
  2. The rise of 6/8/12-week bootcamps had thrust a lot of eager, inexperienced people into the job market, who had great portfolios, but a shallow understanding of the breadth of work to be done, and a lack of experience with clients/processes, etc.

My own experiences revealed that there was a lack of diverse work backgrounds at play, as well. I've been in agency world for 17 years, I take NDAs seriously because it's what professionals do. In agency world, you're under one broad NDA for the agency/holding company, and usually another NDA specific to each client you work with. For example, I have an NDA for a client that prohibits me from mentioning their name. I have another NDA that prohibits me from showing my work at one company for 5 years. 

The solution to these limits is one that was so commonly used, it's rote:

  1. you only show work in person;
  2. you never put work online, and
  3. you don't provide leave-behinds. 

I never once had any employer or recruiter take issue with that approach, until now. 

At the moment, there seems to be a blanket approach to hiring that fails to take into account work history, eschews personal conversation, and assumes that everyone is trying to pull a fast one. Long, drawn out interview processes, and design exercises are the rule of the day. 

I observed, over the last year, as no less a UX luminary than Jared Spool dismissed the UX portfolio requirement, only to have people react with a vehemence uncalled for in any sense. How, the masses asked, will we know what they can do? How will we know their process? 

By talking with them, replied Jared, during an interview. A practical, sensible answer that did nothing to quell the insistence that interviews were horribly insufficient. There certainly appeared to be a near insatiable demand for assurance and proof underlying this pro-portfolio movement.

I just didn't understand why people were nodding along, and saying, 'Oh yes, of course, we need to send our work samples over without the kind of narrative and conversation we provide to our clients'. Nowhere did I see any sort of clear requirements provided around what a hiring manager expected to see in a portfolio—surely they can't all want to see exactly the same things. 

Privately, other UX practitioners were sharing their frustrations with me about portfolios, and wildly differing job descriptions, and expectations. I personally experienced interviews that wouldn't be out of place on an episode of "The Twilight Zone". My own reviews of UX job descriptions left me hovering between hysterical laughter, and gobsmacked disbelief. 

Clearly, something had gone terribly awry. And I like nothing more than a good detective story, so I decided to try and get to the bottom of this UX portfolio business.


Can You Do UX Research On a Thing You Can't See? Can You Do It In a Week?

The first most frustrating thing that can happen to a User Experience professional is for all aspects of user research and usability to be summarily cut from a project budget.

The second most frustrating thing that can happen to a User Experience professional is for there to be budget for research and usability, but attached to a absurdly short timeline.

The third most frustrating thing that can happen to a User Experience professional is to not have access to the site for which the research and usability is to be conducted.

In the 4th quarter of last year, I worked on two projects that met the second and third criteria, simultaneously. This was my first time working with this agency, and both my project teams were remote. We were all voices on a phone to each other. 

I did not go crazy. I did not yell. I got the work done, and both the clients were pleased.

Let me tell you the story.


Wait: why aren't there any images of deliverables in this case study?

A couple of reasons:

  1. The work for Client #1 was for an intranet. Intranets are, by definition, proprietary. I wasn't even able to access the site, and had to work from a handful of screen captures, and PowerPoint mockups. (Typically, access to internal client sites require separate, extensive, paperwork and additional background screening that can take at least 2 weeks if not longer. Because I was a contractor, and I'm sure that the agency had no interest in letting the client know that, and the deadline was insanely tight, this was never an option.) 

  2. Client #2 was a company that the agency I was contracting with was incredibly eager to develop a long term relationship with. As such, it was a clear cut case of, "Just get it done, and make them happy." The goals and purpose of the usability work were never shared with my team. 

And this is reason #3.

And this is reason #3.

    EOY Budget That Must Be Spent

    Both projects were driven by the typical enterprise requirements that whatever budget is not spent, is lost—and in most companies that also means the department takes a negative hit to next year's budget as well. 

    Client #1 was a huge, international personal care corporation. They were about to move their intranet to a brand new platform, and needed help crossing the finish line. The team was internal, tiny, and trying to complete this work on top of their ordinary workloads. The project had to be done by the end of the year.

    Client #2 was a huge, multinational conglomerate. They had recently overhauled their internal career path training and documentation, a combination of clickable PDFs, and content from a third-party provider. The team was internal, tiny, and seemed to be driven by powerful, yet mysterious, political factors. They wanted usability testing. We had one week to do it—in December, before the end of the year.

    Client #1: Balancing My Employer With the Client

    I was a UX Lead contractor at a digital agency for both projects. What this has always meant in practice is having two clients: the agency, and the agency's client. My job, always, is to meet the agency's client's needs, of course, but also to balance the requirements the agency has of me. 

    And sometimes, these things are in conflict.

    Client #1 was very clear in all the documentation provided that they did not want research. They had conducted all the research they needed. Based on that research, they had provided the agency with a PowerPoint outlining, in significant detail, what pages need to be designed, the navigation, and what content to put on each of the pages.

    In short, we were there to color in the lines. I've worked on these kinds of projects before, and while they aren't the most rewarding, you realize that you're there to take the load off your client, and help them look like heroes. Our designs, and the move to the new intranet platform, were also supposed to be so fantastic that it would help the client team convince other departments to also moved to the new platform.

    Again: we're there to help them look like heroes. Easy peasey.

    During the internal team kick off call, the agency team expressed a desire to 'do the right thing', and press for a longer project, with more research, and time. After all, they reasoned, intranets are complicated, and we should make sure that it gets done the right way. 

    They were also very keen to establish an ongoing relationship with this client.

    The challenge I was facing was that the client had been very clear: no research. There was neither time, nor budget, for the 3+ weeks of user interviews that the agency team had expressed interest in (e.g., 'the right way') during the internal kick-off. However, the PM asked me to lead the discussion with the client, and see if we could bring them around to our way of thinking.

    I had a couple of priorities: 1) to find out if we could even get access to the intranet in order to dig around and understand it (spoiler alert: we couldn't); 2) figure out how to gently, but firmly, help my employer, the agency, hear the client's desire to move forward without research; 3) assure the client that we understood their 'no research' request, but we just had a few clarifying questions to ensure that we had all the information we needed to move into wireframing.

    In short: thread a needle in a room lit only by candlelight.

    I am an ace improvisationalist when it comes to working with clients. I make small moves, wait for reactions, and then, more small moves. Though I had some fairly solid assumptions entering into the client meeting (spoiler alert: the assumptions were correct), the small moves allow me to adjust on the fly as needed. I listen, I process, I adjust. If something catches me off guard, I'm more apt than not to note it, a la, "Wow, that's a little surprising, can you tell me more about XYZ?" 

    Through a series of gentle, small questions, as well as re-stating what the client said, I was able to make it clear to the agency that this project really wasn't a huge intranet redesign undertaking, and the client was able to clarify their needs. 

    You Just Get Comfortable With Being Wrong

    As for how you do wireframes when you can't see an intranet: you just do the best you can. I had never worked with this particular platform before, though the agency team was well versed in it. I asked a lot of questions, and I was okay with being wrong. I had a list of what they wanted, so I worked with that. 

    By being wrong, and getting feedback, and talking, you eventually arrive at the right place. The wireframes were approved, and we moved into visual design. And guess what? We were still wrong. The client asked for another design exploration, which wasn't in scope, but we worked it through. 

    So, the intranet site has gone live with the new homepage and landing pages we designed. I will never see it. That's just how things are. 

    Client #2: The World's Fastest International Usability Test For A Site I Can't Access

    There was a lot of confusion. The agency team had the site log in at one point, but it stopped working. The client didn't know, or didn't understand, that we didn't have access to the site. In any event, our team (myself, a content strategist, and a PM) were pretty unnerved: one week to conduct international web conference usability tests, half on clickable PDFs, half on an IP-restricted intranet training site. We had a sample batch of PDFs, which we didn't really understand the purpose of, and no clue what the web site was about.

    We agreed that we would raise, gently, our concerns with the client, and try to push back on what seemed like a totally random date.

    Spoiler alert: it didn't work. Moreover, the invitations with the usability participants were already flooding in, for the following week. 5, 12 hour days in front of me and the content strategist.

    We spent about 20 minutes of the call on WebEx as one of the client team walked through the training web site. But it's just not the same as having the time to explore it on your own. There also wasn't enough time to ask in depth questions about the PDFs. We at least managed to get the client to agree to have one of their team members on every call so that they could navigate to the website on the WebEx, allowing me to see the site and track the progress of the participant through the tasks. 

    This was the single most bizarre experience of my career. All right, I thought, fine. Let's just wing it!

    I opened up OneNote and typed out a quick and dirty usability script—all very high level questions that would at least allow me to improvise—and shared that with the CS and PM for comment. They were just as much in the dark as I was, so they sent back thumbs up. The CS wanted to dig a bit into brand perception, so she added a section of questions for that topic. The CS and I were going to be running the sessions, about a 90% me/10% CS split in terms of responsibility

    The fear was simple: we didn't know WHY we were conducting these tests, so we had no idea what we were supposed to be looking for. To our eyes, the PDFs were not ideal: long, verbose, and awkwardly linked, their purpose as a tool for career planning was opaque. We knew the site had some sort of multimedia, but we wouldn't know more until we were 'walking' a participant through the site (read: when we noticed a link and decided to ask the person to click it). 

    The participant pool was weighted heavily toward Europe, the Middle East, and Asia. Overall the interviews went very well, and we were able to continuously improvise, and adjust questions as we went. We asked questions in order to understand the context of these materials: how did people plan their careers at the company? We learned a lot of things that weren't surprising (a lot of DIY, personal networking) given the labyrinthine nature of the documents in front of us (3, 50+page PDFs for each department, explaining the variety of competencies, and career paths, available to employees). 

    We only ran into one serious roadblock: an employee in China had very low English language skills, and we learned that she thought this was going to be a training session for her. Then, after I explained what we were doing, she thought we were testing her. At this point, I felt terrible: she was confused, and we weren't going to bridge the language divide, so I thanked her for her time, and we ended the call. Overall, we learned that, world wide, employees were routing around the overly complicated career planning process in remarkably similar ways. 

    The week went by in an absolute blur. I put together a deck with the findings, and shared that with the CS and the PM by Wednesday of the following week. Since all of us remained in the dark about the real goals of the project, we didn't know how the deck would be received. 

    To our extreme surprise, and relief, the client was really receptive to the findings when we presented on Thursday. We advocated for moving the PDFs onto the web, to take better advantage of the interconnected content. The training course site had huge issues with repetitive and vague titles for content, as well as a lot of clicks to get to said content. Oddly, the lead client was not on the call, and the budget literally ran out the day of our presentation, so our report went out into the void. 

    Such Is the Freelancing Life

    These are some of the more extreme examples of projects I've been a part of throughout my time as a freelancer. Most projects are pretty typical: you walk in, the SOW is signed, the scope is fixed, timeline set. You come in and do what the line items say need to be done. 

    What I've learned is to be flexible, and pay attention: you listen to your employer, your team mates, and the client. You look for opportunities, as well as for potential issues. You have to be able to see the future a little, and that's something that only comes through experience. Once you've lived through a couple of troublesome projects, you've got a toolkit to use to help yourself and your team get through the next one. 

    The Impossibility of Reviewing UX Portfolios

    I think it's what some well-meaning, but utterly clueless, professor advised: ask people in the field to review your UX portfolio.

    It sounds, on the face of it, like a good idea. But to be clear: approaching a stranger with no more than "here's a link, can you take a look" is pretty rude. So, you know: don't do that.

    In reality, if you're in a program—especially a graduate program—that purports to teach you professional skills, and their teaching staff can't pull together a decent in-house review program. . . well, friend, you probably wasted your money. Enjoy paying back those student loans!

    However, what this young person had handed me was an opportunity to take a crack at actually reviewing one of these UX portfolio things. While I have, when interviewing candidates, looked at their past work with them, I have never looked at portfolios for UX work. (And honestly, most of the time, I wouldn't even look at provided work samples before an interview for the simple reason that I'm much more interested in the person, not the deliverables.)

    In the past, when I've googled 'UX Portfolio', every single instance has been a visual design portfolio. Every. Single. Instance. That was, for me, telling.

    I sat down, clicked on the link, and . . . sighed.

    I looked at the projects, I read—okay, I skimmed—the descriptions, and while it was all nice enough looking, the writing was pretty sub-par. The person in question was ESL, so I gave it a bit of a break, but then, that makes it harder to judge the quality of thinking. So I was left with nice images, and passable copy, and . . . then what?

    This student had—as is the nature of these noxious graduate programs—done a bit of everything, including industrial design. There were photos of paper prototypes (these days, there's almost no reason to do this from a practical standpoint), and a confession that it was a lot of work. It seems as though the student had completed their course work, but it was all very rote. I had no sense of the student as practitioner. Why were they even studying Interaction Design? 

    I stared at the screen: what on earth was the point of this thing? Was it supposed to help me decide whether to call the student in for an interview? If so, the student was already hobbled by a lack of work history, and was only truly qualified for either an intern position, or a very junior position. 

    Knowing how to make a sitemap is all well and good, but you still have to be taught how to do the work in the context of a project, and how to work with a multidisciplinary team—all things arguably more important than a spiffy portfolio. I can teach you to make a sitemap—it will take about an hour if you pay attention—but real skills, like dealing with a suddenly pissed off client who hates everything they signed off on last week, take time. 

    Your portfolio will not tell me if you can learn to do those things. I will have to meet you, we will have to have a conversation. You will need to tell me stories. 

    So, once more, I ask: what is the purpose of a UX portfolio? Aside from telling you very mechanical things like whether a person has experience with annotated wireframes, or created prototypes, what do you actually think you're learning from it? And are any of those things truly differentiators, especially considering the abundant number of bootcamps from which spring more than enough deliverable types to tick off the boxes of a job posting requirements list?

    Hiring managers have been led down a primrose path, and we're going to have to work very hard to steer them back onto more useful winnowing, and interviewing techniques.

    Designing a Better UX Hiring Process

    I've been on both sides of the interviewing table for User Experience positions. As an interviewer, I try to provide the candidate with opportunities to shine. I want to find a great person for a position, and so this is how I've done it:

    1. Have Interview Objectives: Hopefully, you're going to be interviewing multiple people, so you need to know what you're trying to learn from each interview, such as: how does this person handle conflict? How does this person deal with being thrown into the deep end of a project? How does this person feel about collaboration? These are the things you'll use to compare candidates, and find the one that is right for your team.
    2. Be a Decent Human: You're not there to prove how smart you are, pal -- you're the one with the job, so pack up your insecurities and save them for your journal. Even if you're secretly intimidated by the candidate, get over it, and think of it as an opportunity to learn something new. Be polite, be professional, be a decent human. 
    3. Know Their Work History: You should have read their CV, looked at them on LinkedIn, and any other ancillary work-related information out there. Familiarize yourself with the types of companies they've worked at (agencies, consulting firms, etc.), and ask questions about how they found each place different for working in UX. 
    4. Don't Read Their Social Media: You don't care. And even if you do care, YOU DON'T CARE. If a candidate has provided you with their Twitter or FB accounts, ignore them. Let people have a space for their non-work life. And if they haven't, for heaven's sake, don't go look them up. Let people be people. Give them space. The one exception to this is if they have a blog, or posts on Medium, related to UX go read them. Are they good writers? You want clear communicators, always.
    5. Let Them Come Prepared: You should give them an assignment before the interview, such as: tell us about a project you're proudest of, and walk us through any relevant documents or deliverables. Yes, I said you can ask them about deliverables -- but wireframes aren't the point of this portion of the interview, it's letting the candidate tell you a story, and paying attention to what you learn from how the candidate tells you the story. You want to know: what has been their experience being onboarded into a project? What was the entrenched process of the project (because no one gets to pick their own process)? Did they get to talk to the client? 
    6. Allow Them to Be Different Than You: I'm an introvert, so I'm predisposed to recognize that most everyone is more talkative than I am. But interviews can freak out the most gregarious extrovert, and even confident people can have a brain freeze. It's okay -- people have a lot of stuff going on, and if you expect someone to shine 150% the first time you meet them, you're in for wild disappointment. Again, give your candidates every opportunity to shine and be prepared: give them topics and ask them to come with 2-3 questions about the topics of their choosing, for you. If someone was flustered, but you think they are a great candidate, ask to meet with them again. 
    7. Hire People Not Keywords: Don't reject someone because they don't use XYZ Software. You don't care. They can learn how to use it. 
    8. Ask What They Want to Learn Next: This is always interesting -- and it needs to be wide open, not limited to UX. What do they want to learn, and how do they plan to learn it. Someone who is constantly pursuing new knowledge is an absolute diamond. 

    By putting time and effort into designing a better UX hiring format, you will end up with better candidates, and better employees.

    No, I Won't Send You My UX Portfolio. You Shouldn't Ask. I'll Explain.

    It was David Travis who hit the nail on the head as to why UX practitioners find themselves being asked for portfolios (my emphasis):

    Portfolios are common in visual arts, like design and photography. Picasso, I’m fairly sure, had a portfolio. But they are uncommon to the point of being unheard of in scientific fields, like research and technology. Einstein, I’m fairly sure, didn’t have a portfolio.
    But at some point over the last decade, a clueless recruiter or employer asked a user experience researcher for their portfolio. In a panic, the job candidate pulled something together and now it’s just seen as a given that a UX practitioner will have a portfolio that illustrates their work — even if they don’t create visual designs.

    Other people have waded into the debate over UX portfolios (Timothy Jaeger in particular makes very salient points, as does Megan Kierstead here and here), and yet here we all are, being asked over and over to submit portfolios before a hiring manager/HR person will even speak to us.

    Congratulations UX, and welcome to your much desired seat at the table! You sang the praises of your precious deliverables for so long that now, that's all anyone cares about. Great success! We're now reduced to production monkeys -- well done!

    So, allow me to try and turn back this horrible tide of mediocrity, and poor hiring practice. It all comes down to one very simple fact: 98% of what a UX practitioner does is invisible, and results in the 2% you can see (wireframes, prototypes, sitemaps, personas, etc).

    You're absolutely terrified now, aren't you? Good.

    The value of a User Experience professional exists entirely in their ability to analyze, critique, and understand a problem space. Anyone -- literally anyone -- can draw a wireframe and make it look beautiful. Deliverables have zero value without analysis and understanding. 

    If you're speaking to a UX practitioner who has spent time in an Agile environment (hi!), then we don't even make deliverables as a hiring manager understands them. The last time I made a wireframe was in the summer of 2014. Between September 2014 and June 2016, my design work consisted entirely of whiteboard sketches with my team, or dirty edits of existing screens in PowerPoint (I was a Product Owner, so I wasn't given Photoshop) to solidify an idea the team had discussed, and add it to Jira for a user story. 

    More than that, in true Scrum fashion, design of our product was a team responsibility. No longer was I UX Moses bringing down the Wireframe Commandments from high atop the Design Mountain. 

    And I have to tell you: it was a relief. For the first time, I was sharing the work with other people, and helping them learn how to think through flows, and experiences, with the eyes of a customer. This, I thought, is how design ought to be done.

    My UX portfolio has any number of deliverables, but they have no value apart from the context, and stories, of how they came to be: the client and team I worked with, the challenges we faced, the victories, and disappointments. When you ask to see my portfolio without hearing the stories, you're missing the stuff that really matters: you're missing the 98% of what I do. 

    Anyone can make a wireframe, or a sitemap. It's honestly not hard, and god knows that there are plenty of overly fetishized tools out there that make them really pretty. But does a person know how to think, how to fail, how to pick themselves up again, how to work past blockers, how to work with a team, how to sit with a problem and chew on it until the edges become familiar?

    You will never find those answers in a portfolio, friends. You will only find those answers by talking to the person. And isn't that what we tell our clients? You have to do user research! You can't just look at your data or stats or reports! You have to understand the people buying and using your product or service. 

    How ironic, and sad, that we've forgotten. 

    EVE Fanfest, Reykjavik, Iceland :: April 2016

    Internet Spaceship nerds gathered in Reykjavik to have fun, and learn about upcoming features in our favorite game. Friendship is the best ship!