Portfolios: The problem with NDA’s and Internal Projects

User Experience Portfolio’s aren’t the easiest thing to portray online. I liken it to other fields where the deliverable result is usually a series of intangible activities and the usage of talents; talents gained through experience.

For a Graphic Artist, it is very easy to make a portfolio. Show examples of your work, make a gallery, and maybe make a few notes on your technique. People want to see your talent as an artist.

The same can be said for a web developer. A long list of websites created, complete with screenshots, links to the live site, maybe a few wireframes (if you even bothered to make any). People want a website built, you show them websites you’ve built, and if they are good sites, people want you to build them a good site as well.

Demonstrating your role as a UX practitioner.

For UX, showing your “talent” is a more difficult task. How do you show all the meetings and brainstorming sessions? Or how you presented ideas and workflows to your VP’s and key corporate stakeholders? Or how you successfully took a whiteboard session to paper prototypes to Axure to mockups to a final product when all of that is under NDA’s and the intellectual property of the company you were working for at the time?

Internal projects, proprietary software, intangible “work” that takes place in conversation and talk with the rest of the team – these things aren’t something that can be shown in a jQuery lightbox gallery. How do you get around that?

Here are some things I’ve thought of that can demonstrate knowledge, talent and ability, without disclosing things that are either private, under NDA contracts, or just intangible.

1. The easiest, show what you can. If you’ve got a product (site, interface, interaction) that is public, by all means show the pictures of the whiteboard, the graph paper wireframes drawn with a sharpie, the digital wireframes, mockups, and then how they all compare to the finished site.
2. Talk about the project in obfuscated, generalized fashion. Without breaking any NDAs, you can talk about the general process of conceiving a mobile app, how needs were determined, how interface and interaction challenges were identified and overcome, and the process of taking all that into a working model and eventual prototype/product. I liken this to someone who has to give a lecture or keynote speech. You talk about your brain and how it works, not necessarily what you were working on.
3. Write. I personally like to write blog articles on generalized topics. You can show knowledge, depth, thought process, and what you hope is evidence of talent and ability. This may or may not work, since you could be plagiarizing something from another blog. But I like to think that creating an information and entertaining piece may help convince someone that you know what you’re talking about. And if you’re really super great, they might even assume you’re and expert.
4. Make a “proof of knowledge” project. A fictitious site, app, whatever. This way, you go through the process of thinking of an idea, wireframing it, designing the information organization (architecture), mockups, and even development schedules. This way, you can show the UX process without having to actually develop a product. This is probably the best method of showing your skill (other than showing a real project). It can be time consuming, so pick something that will really highlight everything. I still need to do one of this; it’s in the hopper.

I really don’t have an answer to this. Hopefully you, and I, can provide enough data to get an on-site interview, at which point you can just attack the whiteboard for the interview and really show them your toolbox.

I think more than anything else, though, is that people will be more apt to hire a person that can show them what they can do for the company in the future, not necessarily what they have done in the past. It’s not a portfolio that is hired, it’s a person.