Category Archives: Nadyne

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.

 

women

“Beyond the 29%: The Cities with the Most Women in Tech and What We Can Learn from Them”

Anita Andrews analyzed Meetup data to see what could be learnt about the global tech scene.  It’s not a perfect analysis — lots of tech events happen outside of Meetup, for example.  There’s still a lot of interesting stuff in here, and a great jumping off point for additional research.  Here’s an interesting point about Las Vegas, the only city with a majority of women in tech:

In Las Vegas, women make up 65% of the tech scene. This is the only top tech center where women are the majority. Why the anomaly?

Outside of the tech bubble, Vegas is a welcoming place for females on a number of fronts. For one, the city has had a female mayor, Carolyn Goodman, since 2011. Across the country, only 18.4% of cities with populations over 30,000 can claim that level of female leadership. Additionally, Nevada ranks highest in the nation for gender paycheck equality, with women earning around 85 cents on the dollar compared to men.

Not that I’m moving to Las Vegas anytime soon.  Oakland comes in #2 at 46.8%, though …

Edited at 12:35pm: I forgot the link to the post.

women

stop talking about the pipeline problem

2 Comments

I attended a talk last week where an executive was asked about what we can do to better support women in tech.  He listed a couple of initiatives, and closed with a lengthy discussion of the pipeline problem.  The oft-quoted stat, which he included, is that only 18% of computer science degrees are being awarded to women.  It’s time to stop talking about the pipeline problem.

The pipeline problem takes attention away from the real problems that face women in tech today.  The pipeline problem is part of the problem that tech companies have in hiring women who have just completed their college.  The pipeline problem is not the problem for the population of women already in tech.  It ignores that women drop out of technical careers at a significantly higher rate than other careers.  It ignores that women have difficulty acquiring mentors and champions.  It ignores that women are more likely to be judged to be less competent without clear points of excellence, and that they are more likely to be judged as not likable (“bossy”, “pushy”), and that being both competent and likable are important for career success.

The pipeline problem makes the problem someone else’s.  Tech companies say, if only colleges would award more CS degrees to women.  Colleges point out that women aren’t starting CS programs, let alone finishing them, so the problem is really that high schools aren’t preparing girls for CS degrees.  High schools will say that girls aren’t signing up for CS courses, so it must be that middle school isn’t making CS interesting to girls.  Everyone gets to point their finger elsewhere.  No-one takes responsibility.  No-one is accountable.

The pipeline problem ignores that having a job in tech doesn’t require a CS degree.  While I do have a CS degree, many of my colleagues don’t.  My previous officemate’s degree was in history.  One of the best developers I’ve ever met has a degree in philosophy.  Getting a job in tech is not dependent on having a CS degree.  There are lots of jobs in tech, like quality assurance or technical writing or program management, where a CS degree isn’t even necessarily the most desirable degree.  Many of my user experience colleagues have degrees in psychology or the arts.

Focusing on the pipeline problem is an easy answer to a difficult question.  It gives executives an easy out when confronted with the problem.  We do need to do more to get girls interested in technical careers.  We don’t need to pretend that it’s the only problem facing women in tech.

Nadyne

The Atlantic wants “Adventures with Technology” stories

The Atlantic has put out an open call for stories around the theme “Adventures with Technology”.  Here’s what they’ve got to say:

Here’s what we’re looking for: Adventures with technology. We want exciting stories—the kind that warrant telling your friends—about what it’s like living with technology these days. We want you to be able to execute quickly, on a scale measured in days. You don’t have to be at the center of the story, but someone should be.

I’m quite sure some of my friends have excellent stories …