Category Archives: user experience

user experience

what’s next?

I recently conducted research which revealed that we had failed to consider one of the most important questions for our users: what’s next?  During the research, users successfully got through each individual step.  When it was time to transition to the next step, they couldn’t figure out what to do.  They knew what their end goal was, they couldn’t figure out how to get there.  One of my recommendations to the team is to consider how we will guide the user through the whole process so that people can accomplish what they set out to do.

When we develop applications, we break workflows up into features, and we often break up features into smaller pieces.  This process helps us build software.  It’s very easy for this process to make its way into the interaction design process: we design part of a workflow, and forget to design the glue between the individual parts of the workflow that turns it from a string of features into a workflow that helps users accomplish their goal.

Laura Klein looked at this problem from the other direction: coming up with an idea to improve your product, and then watching it get bigger and bigger as you consider what happens next.  Nothing exists in a vacuum.  There is always something that happens next.  A successful product considers what happens next, and sets its users up for success in getting to that next step and accomplishing what they really want to accomplish.

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%. ↩
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.

user experience

“Know Thy User: The Role of Research in Great Interactive Design”

I stumbled across a slideshow from David Sherwin of frog design, giving an excellent introduction to user research and how to incorporate it into the design process.  In the presentation, he answers the following questions:

  1. What is user research?
  2. Why should I include user research on projects?
  3. When should user research be part of projects?
  4. Who do we include in user research?
  5. Where should I conduct user research?
  6. How do I get started doing user research?

There’s so much great material in here.  Check it out.

user experience

our feature name, your goal

I’m working on user research for vCloud Automation Center1.  As we’ve been discussing the research, I’ve observed a common misunderstanding of how we talk to our users.

As I’ve been creating the discussion guide, I have been careful in my wording.  The wording that I use in the discussion guide matches, as closely as I can manage, the real-world goal of the user.  The application team has asked me why I’m not using the feature name.  After all, they say, their users already know the feature name, so why not use it?  One member of the team said that if we were studying bank accounts, we would expect that our users understood the basic concepts of bank accounts.

This is a great example of the difference between our feature name and your goal.  If I were conducting research about online banking, I would not ask a user to check their balance. Instead, I would ask them how much money that they have available2.  “Balance” is the bank’s term, and comes from accounting; the user might or might not think of the contents of their bank account in that way.

Likewise, I would not ask someone to use online bill pay. Instead, I would hand them an electricity bill and ask them how they would handle it. Framing the task as a real-world scenario allows us to gather much richer data. For example, if the user says that they would write a cheque, then we can learn why they would choose to write a cheque. Thus, we could identify blockers to or concerns about using online bill pay. Once the user tells us that they would write a cheque, I would ask why they would choose that method, and then ask the user if they could accomplish the task in another way, and repeat this until they get to online bill pay (or, if necessary, explicitly point them to online bill pay). We both gather data that is specific to the workflow of paying a bill online as well as data about user thoughts, concerns, and preferences about the concept of online bill pay.

In considering your goals instead of just focusing on our features, we learn more about what you want to accomplish and how you think about it.  If we focus solely on our features, we will probably make improvements to our features.  We won’t get the benefit of the deeper insight that could lead to an even better design.

Edited 7/9 22:11 to correct a typo (thanks, @jackbrewster!).

  1. Are you a current vCAC user and want to participate?  Fill out this survey to indicate your interest and tell us a bit about how you use vCAC. ↩
  2. Interestingly, the online-only bank Simple uses the term “safe to spend” in addition to “balance”. ↩
Apple, iPhone, user experience

in retrospect

I gave a talk at AltConf a few weeks ago entitled “user research for awesome products”.  In it, I used quotes from the launch of the iPhone to illustrate the central tenets of user research and how it contributes to making a fantastic product.  During the talk, I reminded my audience that the most popular phone in 2007 was the Motorola Razr flip phone.  I discussed some of the shortcomings of flip phones of the era, such as texting and taking pictures.  I also talked about how we didn’t didn’t perceive them as shortcomings because they were as good as or better than any alternative we had.  I discussed other ways the iPhone understood our needs and used the technology to support the goals of real live people.

When I read a recent Gizmodo piece about someone who gave up their iPhone for a month in exchange for a Razr, it all felt quite familiar.  In retrospect, the Razr feels weird and clunky and useless.  At the time, the Razr was awesome.  Smartphones have changed how we communicate with others, navigate our world, and spend our spare time.  Her article is a great companion piece to my talk, full of examples of how much our expectations have changed as a result of the iPhone.

user experience

“Eight Traits of an Incredible User Experience Professional”

Stef Miller wrote a great blog post about “Eight Traits of an Incredible User Experience Professional”.  The whole post resonated with me, especially this point:

7) Flexible/adaptable
Things change. In the world of agile process and scrum teams, adaptation is the name of the game. Maintaining a level of flexibility and being prepared to make iterations is a quality that speaks volumes for the nimble work done by UX pros.