Is a UX portfolio necessary? Should UX designers / researchers have a portfolio? IMHO, a UX portfolio is necessary but shouldn't be in an ideal world.
Some further reading links are below.
Currently, I've spent a lot of time putting together a web-based summary and a more complete print-based version to illustrate my process and the problems I've encountered. I've had to - recruiters have told me that it's expected and necessary for me to have a portfolio to be considered. The portfolio that got me interviews and jobs last year is now way too short.
But I also believe that a portfolio should not be necessary and there are X reasons why:
1) Documents cannot convey the true context of real-life work
2) A lot of UX thinking is hard to document thoroughly
3) People are after different levels of description
4) A lot of gatekeepers know little about UX
5) UX research & testing is hard to concisely communicate
Documents cannot convey the true context of real-life work
But from my 12 years experience in this field (and 16 years experience of web design), a portfolio only serves to gain immediate superficial attention. They rarely explain what the exact problems were solved and how they were challenged and met.
If a portfolio discussed a client and said, "This was the 5th time this project had been attempted: all past efforts had failed due to the clients' politics. I successfully pushed it through with 16 client stakeholders of a large, long-established multinational corporation most of whom cared most for building their empire rather than making the best quality product" it would sound bad particularly if the clients name was there despite being an excellent achievement in UX. Would I want to hire someone who bitches about their works' clients, even if they speak the truth? So this kind of critical information is hard to communicate.
A lot of UX thinking is hard to document thoroughly
I spend a lot of my work time thinking. I'll often go unapologetically to a coffee shop, sit down with a Moleskine and pencil and start jotting things down. Most of it's nonsense but I find even a change of situation to be conducive to creative thinking. I'd be short-changing the people who pay me money if I didn't do this.
What I'm trying to do is establish my own mental model (see Gentner & Stevens rather than Johnson-Laird and certainly not Young) about users' mental models - a supra-meta-mental model if you will! We all do it but to different degrees depending upon what information we have about users, what problems need to be solved and various other constraints.
There are artifacts from this thinking but they don't communicate well: Random sketches (with doodles inevitably thrown in) are the only really solid ones I have - they remain ideas until I can document them formally - and these documents don't show how I arrived at the solution, at least not without a long-winded (and frankly bizarre) explanation ("Well, I was reading a Mr Man book to my 3 year old daughter and one of the pictures of a house in a tree caught my attention. Somehow I put 2 and 2 together and realised that 'bit of information C' should go above 'bit of information A' and 'function B'." - this is really less than impressive even if it's honest).
Okay, we can write a corporate-friendly version ("I organised the UX team to ideate using concept-exploration and a semantic association task game") but this is nonsense and untrue.
People are after different levels of description
When reading about a problem, hirers are after different levels of explanation. It's a fact.
Some will read, "The problem was to design against a large set of business and legal constraints and I did this by paper wireframes, blah, blah, blah" and feel satisfied. After all, the candidate has shown that they have designed with business constraints in mind so that's good.
Personally (and there are others who feel the same), I feel this is superficial. What business and legal constraints? I want to know the detail before I can judge whether this work is good or not.
Example: When I worked for a bank, the business requirements were heavy: SOX compliance alone ensured that even short projects had 30 pages of constraints. The large ones - they were big documents. Designing against these was difficult because just taking the requirements in was an effort.
But I also cannot talk about the exact constraints because they are (or very well could be) corporate secrets. They're not for me to tell the outside world. This means that they have no place on a portfolio and hirers like myself would feel unsatisfied without this detail. This implies that portfolios are not the way to communicate UX ability.
To provide enough detail to make it worthwhile means including a lot of stuff that the hirer might not want to read. They're interest might be in navigating corporate politics; it might be in hammering through as good a design as possible against staid stakeholders; it might be whether they used
Either the description is too long or there's just not enough detail.
A lot of gatekeepers know little about UX
Even a few people actually within UX don't know much about what UX really is.
But a lot of gatekeepers (HR, recruiters, creative background people) don't know much about what UX really is. It's not about graphic design; it's not about development or coding; it's not about business requirements (though all of these play a role). What differentiates UX from every other form of design is people:
knowing and finding out about how people think and behave and synthesising a solution that incorporates those user requirements.
It's why the word 'user' is in 'user experience'. If your work has no touch-points with users, then it's not UX.
Sadly, I'm encountering increasing numbers of people who just don't seem to realise this. Example: I was asked what my UX background was recently: "Are you from a design or development background?" The answer was neither: I'm a psychologist (though I can do limited graphic design and I can program to a surprising level - roistr.com is all my own work including the engine that drives it; and I wrote SalStat, a statistics program with a GUI back in the early 2000s including a lot of statistical tests - Mmmm, linear algebra!).
UX research & testing is hard to concisely communicate
I've done a lot of UX research and testing. My PhD is all research and even simple findings can be very hard to communicate to an expert audience never mind a naive one. Yeah it's our job but the research I do tends to be on a big scale. One I did recently featured something like 30-odd graphs.
However, a portfolio is a poor place to discuss this. This is because I cannot communicate the detail without releasing some very important corporate secrets. I can give you an anonymised version but it takes away all context and communicates nothing useful, at least nothing I'd be happy with.
Usability testing is similar. How can I communicate 10 hours of interviews and subsequent content analysis on the transcriptions? I'm good enough at my job to actually know what content analysis is and how to do it effectively (a rare skill in UX). But it's very challenging to communicate this: without context or detail, it's meaningless; with context and detail, it's breaking confidentiality. Besides, how does a hirer know that the work is of high quality? Very few in UX know anything about research anyway so there's little feedback coming through. I feel fairly confident in my work because I've been peer-reviewed and published and through a viva with a former Math Olympian (Alan Dix) and consultant to NASA (Andrew Howes). But few people from without a research background have had this training.
We need portfolios in order to get work. If we don't have them, jobs will go to those that do, simple as. It's not ideal.
But I would just be grateful if hirers could question the validity of basing decisions on portfolios; and also be aware of their own assumptions or even better, challenge them. Best would be to challenge themselves: being employed in UX doesn't qualify anyone as an expert.
I'm currently available for hire as a UX designer / researcher.
Now some links with discussions: