All posts by nadyne

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.

Mac, vSphere

“ESXi support for Apple Mac Pro 6,1”

Just a quick post to boost the signal for William Lam’s post “Quick Update – ESXi support for Apple Mac Pro 6,1”:

I know many of you have been asking about ESXi support for the latest Mac Pro 6,1 that was released from Apple late last year and I just wanted to give a quick update. VMware Engineering has been hard at work on getting this new platform certified and supported with ESXi, however, there were some unforeseen challenges that is currently preventing the current version of ESXi to run on the new Mac Pro.

VMware is working closely with Apple’s hardware team to resolve these issues and we expect to have a Mac Pro 6,1 supported with ESXi 5.5 in the future. In the meantime, if you wish to evaluate ESXi on the new Mac Pro (though not officially supported), you can sign up for the new vSphere Beta and run a Beta version of ESXi on the new Mac Pro.

 

 

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.

Apple, VMware

Q&A: why virtualize OS X?

The question of why one would virtualize OS X came up on the Mac Enterprise mailing list this week.  I got asked that question elsewhere this week too, so it seems like it’s time for a blog post on the topic.

Given that the OS X EULA requires that you virtualize OS X on Apple hardware, and given that the only Apple hardware that is fully supported by VMware isn’t the most current Mac Pro1, what are the benefits of virtualizing OS X?

  • More efficient use of resources. Even if you’re just running two VMs on a Mini, that’s half the capex of needing two Minis for the same purpose.
  • The ability to add new servers quickly, without needing to buy new hardware.
    • You can add services that you would never be able to justify the hardware spend.
    • If you get an idea for something that might work in your environment, it’s pretty quick and easy to try it out.  You can create a new VM or clone an existing one and try it out.  It lets you tinker.
  • Easy creation of test environments. For those of us who are developing Apple apps (either Mac or iOS), virtualization makes running different test environments a whole lot easier. I’ve heard from a lot of iOS dev shops that have thousands of OS X VMs that run Xcode for dev and test purposes.
  • If you’ve got That One App that only runs on Snow Leopard, you don’t have to have dedicated hardware for it.
  • If you upgrade something in a VM and it doesn’t go well, you can roll back to an earlier snapshot quickly and easily.
  • In a disaster recovery scenario, you can replicate VMs off-site so that you don’t lose anything.
  • High availability increases your uptime.
  • Storing a VM on external storage allows you to bring up that VM on another host (that’s running Apple hardware, of course).

 

 

  1. You can successfully run vSphere on a Mac Mini, it’s just not a supported configuration.  Here’s a recent blog post from New Relic about doing so. ↩
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 …