Monthly Archives: August 2014

Q&A, user experience

Q&A: UX portfolios

I recently was asked by a student what they should put in their UX portfolio.

This is closely related to the question about UX interviews.  Many UX interviews, both research and design, start with a portfolio review.

For a research portfolio review, I want the researcher to answer the following questions about a project that they worked on:

  • What were the research goals of the project?
  • How did they determine the research goals of the project?
  • How did they select the research method that they did?  (Note that “we were told to do a usability study” is a completely valid answer to this question.)
  • What did they learn in the course of doing their research?
  • How did they share the results of their research with the team?
  • What questions were raised by other stakeholders about the research or the results?
  • What action was taken based on the research?
  • Throughout the research process, who did they communicate with, and how?
  • Looking back on the project, what would they do differently, and why?

For a design portfolio review, I look to answer similar questions:

  • What was the user need that the designer was trying to meet?
  • What design ideas did they try as they went through their design process?
  • How, and from whom, did they gather feedback about their designs?
  • What changes did they make to the design as the project progressed?
  • Throughout the design process, who did they communicate with, and how?
  • How did they share their designs with others?
  • What design trade-offs were made?
  • What is the difference between the design and what was delivered?  Why do those differences exist?
  • Looking back on the project, what would you do differently, and why?

These questions scale to the experience of the researcher or designer.  For a student who has limited experience, perhaps working on a project for a semester that might not ever get delivered, will answer these questions differently.  They might not even have answers to some of these questions.  For someone with a lot of experience, I’m much more interested in how they balanced trade-offs, communicated their design, and ensured that their design got delivered.

I’m not necessarily looking for a beautiful design or world-changing research.  When evaluating a candidate’s portfolio, I’m most interested in how their work fit into the work of the rest of their team and how they worked with the team.  Creating beautiful designs that never get shipped is not the mark of a great designer.  Conducting amazing research that never gets acted upon is not the mark of a great researcher.  Being great at user experience is about the user experience that actually gets into users’ hands.  As Steve Jobs said, real artists ship.

user experience

the power of “thank you”

User researchers are always asking for favors of people.  It’s the nature of research.  You’re asking your design team to help you get prepared for the research, often creating or helping to create the materials that you’ll use in your research.  You’re asking your participants to give up some of their time to be poked and prodded by you1.  You’re asking your application team to make changes to their plans based on what you’ve learned in your research.  It can make a user researcher feel like they’re always taking and never giving.  It’s not true, of course: your work gives your designers and application team better insight, which results in a better product for your users.

I know that I’m asking a lot from many other people as I do my work.  As I’m doing so, I remember to thank them for their work.  I thank my participants for taking the time to talk with me.  I thank the design team for working with me and ensuring that we had the right design artifacts to share with study participants.  I thank the application team for helping me understand what they need to know, what they have time to implement, and how my work fits into their development cycle.  I thank everyone for being involved with the work, for sharing their thoughts and ideas, for listening to what we learned and asking questions to clarify points, and for sharing their thoughts and ideas for how we move forward.

Remembering these simple courtesies helps smooth the way for a user researcher.

  1. Figuratively, not literally. ↩
user experience

the scaling of user experiences

A colleague pointed me at an article by Jonathan Courtney titled “Want the Best User Experience? Make it Harder to Add Features”.  I thought I would read an article that preached to my choir.

I have long advocated delivering fewer and better features over delivering a laundry list of features.  How does a feature fit into the overall user experience?  If we cut part of it, do we negatively impact the user experience?  It is much better to deliver fewer features that create a great user experience, rather than delivering a laundry list of features that don’t quite fit together to meet the user’s needs and goals.

Except the article isn’t actually about being harder to add features.  There is only one sentence that I think comes close to the title of the article, which is this one: “It means that adding features down the line will need to be a careful process of consideration rather than just something that’s tacked on.”  This is dead-on: we shouldn’t just add features to add features.  We should carefully consider how a new feature fits into our existing application and how we can make it fit into our users’ workflow as seamlessly as possible.

Then the author takes us down a completely different path:

We’re at a time when apps and software are becoming more and more focused. Successful companies that previously took the kitchen sink approach have done a u-turn and are now decoupling features to create entirely separate experiences. Foursquare has separated its “checking in” function to Swarm. Facebook created Messages (and many other apps), Path recently released Talk.

Now I see that the article really isn’t about user experience and the number of features in an application.  It is only talking about mobile development, and specifically about social media on mobile.  Even worse, it skips over user reaction to these decisions in mobile social media apps.  A quick glance at the iTunes Store reveals how popular this method is with users. In separating Foursquare into two applications, Foursquare went from having a 4-star rating to a 2.5 star rating, and the new Swarm app has a 1.5 star rating. The current version of Facebook Messenger1 also has a 1.5 star rating. Only Path has retained its 4-star rating, although it’s interesting to note how many of its reviews specifically say that they didn’t use the private message feature before the split (that is, the feature that is now the basis for Talk).

By focusing an application on a single use-case, we run the risk of not thinking about the user’s overall goals and workflow. How do all of these individual use-cases come together to create a workflow? Can users seamlessly continue their workflow, regardless of what application it’s in? Does the concept of single-use application work for desktop or web applications that aren’t social media?  The author provides no evidence.

We should not deliver a laundry list of features, but rather deliver a fantastic experience on a subset of those features. Let’s not deliver 80% of a feature so that we have enough time to get another feature on the laundry list. Let’s deliver 100% of a feature2 that truly meets our users’ needs and helps them accomplish their goals easier and with less cognitive load.

  1. that is, the version where Facebook forced users to use Messenger to send messages; in previous versions of the Facebook and Messenger apps, usage of Messenger was optional. ↩
  2. Okay, maybe 95%. ↩
Apple, Mac, vSphere

more community stories of VMware and Apple OS X in production

My colleague William Lam of Virtually Ghetto has been busily talking to more system administrators who have virtualized OS X in a production environment.  The most recent two are:

This has been an awesome series of blog posts.  I’ve learned a lot!  Want to share your story of using VMware and OS X in production?  Contact William.

Apple, women

“Integrating women into the Apple community”

Brianna Wu, head of development at Giant Spacekat (who have just released their first iOS game, Revolution 60) wrote a great piece titled “Eve wasn’t invited: Integrating women into the Apple community” for Macworld.  The conclusion is fantastic:

When I was a teenager in the 90s, I had few female role models to look up to in computer science; it’s simply not acceptable for this to still be the case in 2014. Next year at WWDC, I want to see at least one woman in a public speaking role during the WWDC keynote. There are many bright, smart, well-spoken female Apple engineers; let’s put them on stage and be role models for their peers and our daughters. Or Apple’s Angela Ahrendts, who may not be a developer, but her business savvy and presentation skills seem like they would be well-utilized at next year’s keynote. And I want to see more women and minorities at WWDC next year. We’re a small crowd, but we do exist, and having more of us at the conference will emphasize this.

Go check out the whole article!

Q&A, user experience

Q&A: UX interviews

1 Comment

During an intern recruiting event, I was asked what I look for in UX interviews.

Your UX skills are necessary, but not sufficient.  If you are a designer, I want to see examples of designs that consider what your user wants to accomplish.  If you are a researcher, I want to see examples of research that illuminate what users want and need, and how you translate that into actionable results.

I look for communication skills.  In UX, our primary job is communication.  We have to share our designs and our research with others, who may or may not understand UX at all.    We have to take feedback about our work, make decisions about that feedback, and communicate the results back to those who gave us the feedback.

I look for negotiation skills.  We might not have the time or resources for the perfect design, or to address all of the issues that were uncovered during user research.  How did you work with the rest of the team to prioritize what would be done, both short-term and long-term?  What compromises did you make?

I look for follow-up skills.  Creating an awesome design or conducting awesome research and not doing anything else is not creating a good UX.  The best design and research impacts the product that is delivered.  If you create a beautiful design that goes nowhere, that is not creating a good UX.  You have to work with the rest of your product team to ensure that your design or research is acted upon, and you have to follow it throughout the product development lifecycle.  If changes are made to your design or to the product that you researched, you should be a part of that conversation so that the team can make informed decisions about the changes to be made and the impact to the UX that changes will have.

All of this scales to where you are in your career.  If you are coming out of college, you likely have had less of an opportunity to follow a whole product design through to release.  You will have examples of communication and negotiation, especially if you have done any group projects or an internship.  The longer that you have been in UX, the more important your communication, negotiation, and follow-up skills are.