Category Archives: user experience

giving back more than we take

This morning, Paul Maritz sent mail to all of VMware talking about where we’re going in 2012.  There’s a lot in it, and I really like seeing this kind of honesty and transparency from my CEO.  In it, he added a core VMware value: giving more than we take.

In my year-plus at VMware, I’ve been doing a lot of that.  I’ve spent a lot of time mentoring others on my team to help them improve their research skills.  I also created VMware’s first internal user experience conference, vUE.  I’ve also just started a series of UX tech talks (which probably deserves a post of its own), the first of which happens at the end of this month.

My goal is to help my organization exemplify user experience excellence for the whole company.  In short, I’m doing two things: modelling user research excellence for my team, and helping our user experience team come together to share expertise and identify areas where we can collaborate and build a better VMware-wide user experience.  As a side effect of these efforts, I want to create a community for our user experience professionals across the company.  This is also part of giving back: I want to build a lasting user experience community where awesome user experience people want to work.

There was a lot for me to like in Paul’s memo.  This particular piece resonated with me because I feel like I’m ahead of the curve.  It’s awesome to see our CEO recognize the importance of efforts like mine.

the elevator pitch for user research

A couple of weeks ago, I attended Michael’s company’s holiday party.  I got caught flat-footed by Michael’s boss, when he asked me the basic question, “what do you do?”  “I’m a researcher at VMware,” I answered blithely.  “What do you research?” he asked.  And this is where I made my mistake: instead of the elevator pitch for user research, I instead answered the question as if it were about what products I’ve worked on.  But that wasn’t the answer that he was looking for, which Michael realized more quickly than I did.  “User experience,” he helpfully pointed out, which at least pointed his boss in the right direction.

User experience is a term that still doesn’t have widespread understanding, even when you’re standing in a roomful of Silicon Valley software engineers.  This is more true for research than design, since most software engineers have at least encountered an interaction designer at some point in their career.  Researchers are more rare.  There’s only three of us at VMware, so I’m never surprised when someone doesn’t know what a user researcher does.  Over time, I’ve developed my elevator pitch for what I do as a user researcher, but I somehow didn’t give that answer this time.

My current elevator pitch is this:

I study how people use things, and figure out how to make it better.

Sometimes I replace “things” with “applications” or even “our products”, but I like “stuff” better because it’s less precise.  There are words that I deliberately don’t use in that pitch, such as “user” or “usability”.  I also make sure that I connect the study with the outcome of making improvements.  It also opens the door for additional conversations, if the questioner is interested.  But if not, it’s a reasonable encapsulation of what I do and why I do it.

And next time, I’ll remember to use it, even when I’m surrounded by my fellow geeks.

the password conundrum

I recently switched my home Internet service from Covad DSL to Comcast Teleworker1.  Almost everything has gone swimmingly so far: signing up online was painless, the tech came out within the assigned window and he was very nice and professional, and my new service is So Much Faster.

After the tech had everything hooked up, I went online to create my account so that I could view my bill and have yet another email address.  They wanted me to create a password of 8-16 characters in length, and that includes 1 upper-case letter, 1 lower-case letter, and one number or special-character.  This is fine by me, since all of my passwords meet these requirements2.  So I fired up 1Password, set it to generate a password that meets these requirements, and put it into the form.  After doing so, I saw this:Comcast said that my password was a good password

I filled out the rest of the page, and I got the following error message:

The password you entered doesn’t meet the minimum criteria for a safe password. Use between 8 and 16 characters with at least 1 lower-case letter, 1 upper-case letter, and 1 number or special character (no spaces, case sensitive).

So I checked my generated password.  In fact, I’ll share it with you, since I couldn’t use it: r9H4ybnAyf+Acw.  It’s the right length (14 characters), it’s of mixed case, it’s got a number, and it’s got a special character too.  As a geek, I know that the + in there could cause a problem, so I generated another password.  This one had a } in it, which also caused a problem.  I went through three more automatically-generated passwords until I finally got one that was acceptable.

There are two user experience issues here:

  1. They have a limited subset of special characters, but they don’t tell you what that subset is.
  2. When you enter your password, the form is validating whether the password is a good one.  However, their validation isn’t correct, since the page says that a password is good, but then the system kicks back an error on submission.  Don’t tell me that my password is good when you won’t accept it!

Strangely, the former point is actually addressed when creating additional accounts.  The page for creating a secondary account is different than the one used for the primary account, and the password field there includes this descriptive text:

8-16 characters. At least one upper case letter, at least one lower case letter, and at least one number or special character (! @ # $ % ^ & *) are required. No spaces. Case-sensitive.

This would have saved me a few erroneous form submissions if they had told me this when I was creating my account!  The basic information is still the same, but they specify which special characters are acceptable.

Many companies forget about the first user experience.  I make fun of unboxing videos, but getting your new item out of the packaging is part of the user experience.  Your first few minutes are where your first impression gets created, and that first impression is an important one.  It sets your expectations.  By not paying attention to the details of your first user experience, you can inadvertently set expectations that you don’t want set.  On one hand, I’m happy that Comcast is enforcing passwords that are more secure than usual.  On the other hand, I’m not happy that they don’t give me all of the information that I need.  It means that I don’t entirely trust them now.

  1. Yes, I’m well aware of the issues that some folks have experienced with Comcast.
  2. Well, to be completely accurate, this isn’t true.  I have several passwords that are longer than 16 characters.

tell me more

This morning, I conducted some research with one of our customer councils.  I asked them some questions about how they go about things today, and then let one of the designers on my team show them some of his very early design thinking about how we want to improve matters in the future.  It was a great session: the participants gave me great information about the current state of affairs, and they also had great feedback about what we presented them and how they could see it fitting into their life.

At the end of the session, someone commented about how I got people talking.  I told them that my secret to getting people to talk boils down to three words: “tell me more”.  Sometimes I’ll provide additional directions, like “tell me more about what happens after the email arrives”, but the basic concept is still the same.  It’s a short prompt to get someone to add in more details or to give clarification. Then I can use this additional information to ask additional questions, get feedback from others, or be able to ensure that what I think that I’ve heard is complete and correct.

People want to be understood, and they want to provide the right level of detail to you.  “Tell me more” tells them that you’re not sure that you’ve understood or that you’re not sure yet if you have the right information from them.  There’s a lot of meaning packed into those three words.  Using them helps you do a better job of gathering data when you’re conducting research.

we’re hiring user experience professionals!

My user experience team has seen phenomenal growth in the year that I’ve been here at VMware, and the trend is continuing.  We’re hiring pretty much across the board.  A quick search on user experience on our jobs website returns 170 openings as of this writing.  Not all of those are on my team1, and there’s plenty of them which are for UI developers, business analysts, and product management.

My team is especially interested in hiring for the following roles:

  • administrative assistant – We need a part-time assistant to help us recruit and schedule usability participants.
  • user experience manager – Manage a team of awesome interaction designers who work across many different VMware applications.
  • interaction designer – Join our team of awesome interaction designers who are working on complex applications.

But wait, there’s more!  My team isn’t the only user experience team at VMware.  There are other UX openings, including the following:

If you’re interested in any of these roles, or if you’ve got any questions about what it’s like to work for VMware, email me.

  1. Our growth isn’t going to be quite that phenomenal!

winding down for the year

Thanksgiving has kind of snuck up on me this year.  It’s been an immensely busy year.  I’ve conducted a lot of research.  I also proposed, organized, and led vUE 2011, VMware’s first gathering of its cross-company user experience community.  vUE was held in the first week of November.  I took a few days off afterwards, and suddenly I’ve hit the research doldrums.

Mid-November through mid-January are research doldrums.  Collecting data is hard in that eight-week period.  You can’t get research participants for several days around Thanksgiving, and then people start dropping off the face of the planet in mid-December for the end of the year, and aren’t reliably back in the office until at least a week into January.  You can do some research during this time, but it’s difficult and time-consuming to collect the data.

I’m using these research doldrums to do a few things.  I’m making sure that my wiki is updated with all of the documents I’ve created lately, and making sure that all of the other wiki pages that I should update have everything that they’ve got.  I’m writing up a post-mortem document from vUE that discusses what happened, what we learned, and where we can make improvements for next year’s event.  And I’m beginning to plot out next year’s research, so that I can hit the ground running in January.

research is not regurgitation

I’m sick of the supposed Henry Ford quote.  You know:

If I’d asked customers what they wanted, they would have said ‘a faster horse’.

Of course, this quote is apocryphal1.  The best ones often are.  This apocryphal quote made it all the way to Steve Jobs, who often used it to explain why Apple rarely uses research.

This quote and its repetition shows very little understanding of user research.  No researcher worth their notebook just goes out and says “so, what would you like us to give to you?” and then regurgitates that answer and feels proud of the research that they’ve just done.  I wouldn’t accept that research from the youngest user experience intern, let alone someone who calls themselves a researcher.

When you conduct research, you don’t know what the outcome will be.  Sometimes, you don’t even know what you’re looking for.  You conduct the research looking for that key insight, the unmet and unstated need.  You should, at least occasionally, go out and conduct research with no goal in mind other than, “let’s learn something new”.

After you’ve conducted your research, you analyze it to death.  You don’t just look for the easy quotes where a research participant tells you what they think they want.  You look deeper.  You go over your data with a fine-toothed comb.  You pull apart the data and put it back together in new and exciting ways.  And then you learn something new, and you go back and try to figure out the right thing to do with this new information.

Great research gives you insight that you didn’t have before and that you hadn’t yet imagined.  Great research can help form the basis of a whole new strategy.  Yes, there’s bad research out there that really does just regurgitate what someone said, but don’t let the existence of bad research stop you from conducting truly great research.

  1. Not that this is going to stop people from quoting it.  Is there a word for quotes that aren’t actually quotes?  Other than “bullshit”, I suppose.

one year at VMware!

One year ago today, I joined VMware.  And what a year it’s been!

I’ve done quite a lot of research.  I’ve done research on several things, including  vFabric Data Director, Horizon, Zimbra, vSphere, vCloud, the VMware website, and vCloud Director.  Some of the research has been validation, some of it has been generative.

I created, organized, and managed VMware’s first gathering of its internal user experience community.  Last week, about 60 people came together in Palo Alto to discuss our user experience.

What’s next?  I’ve got three major studies that I’m working on now, all of which are generative research.  They’re all intended to set our user experience direction for future releases.

It’s been an awesome year.  Let’s see what happens next …

creating a space where relationships can be built

Last week, I chaired the first (but not the last) VMware User Experience (vUE) conference.  Throughout my planning and scheming to get vUE going, my goal was simple.  Since this was our first time getting together, we had to have the opportunity to actually take advantage of it.  We had to be able to learn about each other, to share with each other.  Every decision came back to that question: how does this get people talking to and learning from each other?

The first idea that I had was to have everyone do a quick introduction of themselves.

Hi, I’m Nadyne Richmond, I’m a researcher, and I’ve been here for a year.  I work on projects all across VMware.  So far, I’ve done research on vSphere, vCloud, vCloud Director, Horizon, Zimbra, Aurora, and some things that don’t have names yet.  Outside of work, I’m currently reading Reamde by Neal Stephenson.  I live in downtown Mountain View with my husband and our two cats.

But then I imagined 60 of those, and thought that there was a high chance of me falling asleep.  Worse, though, I wasn’t sure if that actually imparted any information that I or anyone else cared about.  I thought that it might not meet my goal of helping people really get to know each other.

That idea evolved into what became the meat of the program: 5-10 minute talks from as many people as possible, in which they talked about their user experience in some way.  I explicitly left this open for interpretation, and I really liked the breadth of talks that came out of it.  The very first of these talks was from one of the newest designers on my team, in which she discussed the differences between what she learned in design school (where you get to start with a problem and decide how to go about tackling it) and what design is like in the real world (where the problem is well-established, and you’re coming into the project in the middle of its cycle so all of the decisions about how to tackle it have long been made).  The last of these talks was from one of our most senior designers talking about a future direction for VMware and how he’s going about it.

To help ensure that we had time to actually talk amongst ourselves, I made one other decision that was at least slightly controversial: mealtimes were sacrosanct.  I received lots of requests to do something with the meals.  “Let’s show a movie!” “How about a design exercise?” “We should have a working lunch.”  I turned down each request.  They were great ideas, and I tried to incorporate them elsewhere.  But I didn’t change the (lack of) structure for the meals.  The meals were only for socializing.

Together, the technical program and the socializing time were scheduled with the intent of creating a space where relationships can be built.  The technical program gave us something to talk about.  Actually, it gave us several different somethings to talk about, since there were so many different short presentations.  You could talk to the presenter and get more information about their topic or their product, you could talk to the people around you about the presentations, you could commiserate with a presenter about how hard it actually is to stick to a very short time for your talk.  The socializing time was built in to make sure that we could actually have those conversations, as informally as possible.  I didn’t just want people to have to go back to their offices and email people — that’s too formal, and would result in fewer relationships actually getting built.

Another thing that we did to help build relationships was to give people something to create.  Every attendee received a 4″ Munny doll, which is a white vinyl doll that you can draw on or otherwise decorate to your heart’s content.  We set out a bunch of multi-colored Sharpies, and let the attendees do the rest.  Some folks did some truly awesome things with their Munnys.  At the end, we took a group shot of the well-decorated Munnys.  This was a great ice-breaker, and helped make more conversations happen.

Was vUE successful?  Based on the feedback so far, the answer appears to be a resounding “YES!”  I can’t tell you how relieved I am.  I was well aware that I was asking for a lot of people, to put aside their work for 2 days (or more, for those who travelled to be here).  Creating vUE was a gamble, and I wasn’t sure if all of the decisions that I had made would actually mean that I met my goal of getting people to build relationships across the company.  There’s definitely some things to do better in the future, of course.  Overall, though, I’m immensely happy with how everything worked out.

VMware User Experience 2011 (vUE 2011)

A few months ago, I proposed to my manager that we needed to do an offsite.  After many discussions and a lot of work done to clarify goals, a conference was born.

VMware’s user experience community is diverse and distributed, much like our extensive product portfolio and our overall development efforts.  My user experience team focuses on vSphere, vCloud, and related products, and is the largest group of user experience people.  There are other user experience people sprinkled throughout the company, sometimes just in ones and twos, other times (especially in the case of an acquisition) a larger team of 5-10.  With such a distributed team, we often don’t have a lot of interaction with each other.  In the case of acquisitions, I noticed that my team tended to have the same set of questions when we heard about a new acquisition:

  • what does this new acquisition do?
  • how do they fit into VMware?
  • who are their users?
  • do they have a user experience team?
  • how do they create their user experience?

When new acquisitions came on board, or when I heard about a user experience person working on another team, I got into the habit of reaching out to them and offering to have lunch if they’re local or a phone call if they’re not.  In doing so, I learned that they had the exact same questions about my team.

In thinking about how to solve this problem, a conference was born.  We named it vUE, which we’re pronouncing “view”1, and it is the first-ever gathering of VMware’s user experience community.  The major goal of this conference is to answer those questions that all of us have had about our applications, the users of those applications, and the processes that create those applications.

Michael Lopp has a great post at Rands in Repose about off-sites2 called Fred Hates It.  In it, he describes three types of off-sites, and why a team member named Fred might not like that off-site.  This post came long after I was already deep into the planning stages for vUE, but it’s helped me to articulate my goals and keep my focus.  One of the types of off-site that he identifies is “we need to understand who we are”, which is exactly where we at VMware are today.

To help reach the goal of understanding ourselves, I’ve set up a program structured around the types of activities we all do as a user experience community.  There are six technical sessions, each of which consists of very short presentations centered around a topic.  Our six topics are as follows:

  • users (who are our users?)
  • user research (what do we do to understand our users?)
  • design process (how do we design?)
  • design collaboration (who do we work with as we design?)
  • visual design (how do we make decisions about our visuals?)
  • data visualization (how do we present large complex sets of data?)

Every attendee was invited to present on one (or more) of these topics, and the majority of our attendees have stepped up to the challenge.  I’m one of the very few people who will be there but who isn’t giving a presentation.  I hope that everyone will forgive me for bowing out, and I really would like to be able to talk about my research, but leading vUE has taken enough time that I just can’t put together a technical presentation too.

The overall response to this idea has been overwhelming.  There are user experience people travelling here from Sofia, Herzliya, and Sydney, not to mention Seattle and Colorado Springs.  As I’ve been talking to my fellow UX people about why we’re doing such a thing, the response has universally been one of excitement and support.  These responses have only gotten stronger as people from outside of Palo Alto have been confirming their attendance.

We’re now one week away from the start of vUE.  Even just getting together so many people from so many corners of the company is a success.  The sessions and presentations that I mentioned above are intended to be the starting point for future conversations.  This is one way for us to know who else is working on mobile projects or data visualization.  As I’ve been organizing this, I’ve learned a lot about my fellow UX colleagues here and have already been able to introduce people who are working on similar problems.  That’s just my efforts: I can’t wait to see what I’ll learn next week when we’re all in the same room together and sharing what we know.

  1. I had originally advocated for vUX, but it was pointed out to me that the name could be (ahem) mispronounced.
  2. The eagle-eyed reader will notice that I’m referring to vUE as a conference and not an off-site.  That’s mostly a result of scale: nearly 70 people were invited. Thus it violates a cardinal rule of off-sites, in that not everyone attending is presenting.