summer internship opportunities for user experience researchers and designers

I mentioned earlier that summer intern season is coming, and that my team has intern openings.  The job openings are listed on our website:

  • user experience research intern — This position reports to me, and is on a project where I really want to see some awesome research.  Read the job description carefully, because there’s some discussion in there of what the project is about, and a great candidate will be able to tell me how they’d go about executing on this project.
  • user experience designer intern — We’ve got several openings, so there are several different summer projects where we’d like an awesome intern to come in.  Here, a great candidate will have a good portfolio and will be able to tell us how they think that they would apply their design skills to the types of problems that we see at VMware.

Interested?  Email me with your cover letter, resume, and portfolio (required for design candidates, not required but still useful for research candidates).

We’ve got other jobs available as well, not just summer interns.  We’re especially interested in hearing from senior interaction designers, such as for this opening.

my conspiracy theory about password expiration

I’m completely and utterly convinced that corporate password reset policies are somehow tied to vacations.  There’s just no other explanation for the fact that, every freakin’ time I go on vacation, my password expires just before, during, or just after my vacation.

So my theory is this.  The system scans my calendar and looks for all-day events that are marked either “busy” or “out of office”.  If it finds one of those, and if that all-day event spans 4 or more days, then it sets my password expiration date to happen somewhere during that time.  I think it might be a random number in the range vacation±3 days.

Which is to say: I leave for vacation on Saturday, and my password expires on Thursday.

the difference between good user research and great user research

This morning, my team discussed the benefits and drawbacks of large-scale A/B testing.  Websites like Google and Amazon often use A/B testing where they randomly show some of their users a new version of a webpage, and measure whether the outcomes are different: a better click-through rate, for example.  There’s a lot be learned in this kind of testing.  It’s a powerful method for websites to learn about how design changes, both major and minor, can impact how users complete their task.

However, it doesn’t give you a complete picture.  It tells you what happened, but it doesn’t tell you why it happened.  One of the differences between good user research and great user research is in what you learn and how you can apply that information in the future.

In good user research, you learn that something happened.  Maybe you’ve learned that a user is completely blocked from finishing a task.  Maybe you’ve learned that users can complete their task 20% faster.  Maybe you’ve learned that, while they’re not doing anything faster, their satisfaction ratings are higher than usual.  Each and every one of these findings is important.

Each and every one of those findings can be made better if you know the reason behind it.  Sometimes it’s reasonably obvious, but oftentimes it’s not1.  When you know the reason why a change has improved or degraded the user’s experience, you have a better opportunity to innovate in the future.  You only have data.  You don’t have insight.

Good user research allows you to react.  It allows you to evolve your designs.  With good user research, you will make improvements.  Your application will be better.

Great user research allows you to learn more about your users.  It gives you insight into how they think and what they’re trying to accomplish.  It allows you to make intuitive leaps and to truly innovate.  With great user research, your greater understanding of your users will allow you to make improvements to your whole business, not just your application.  Your business will be better.

  1. And sometimes you think that the answer is obvious, but it turns out that the obvious answer isn’t the correct answer.

vCloud Client for iPad available now!

In our continuing effort to VMware-ify your iPad, we have a new application available today: vCloud Client for iPad.  You can do quite a lot with it:

  • connect to your VM via RDP, SSH, or VNC
  • create and deploy vApps
  • power apps on and off
  • monitor tasks that are currently running or have recently completed
  • … and more! Check out this blog post for more details.

vCloud Client for iPad joins our other two iPad apps, vSphere Client for iPad and View for iPad.

Q&A: what are the best courses to take in a user experience curriculum?

Last week, I spoke at a networking breakfast at the University of Michigan’s School of Information.  One of the questions that I was asked there was from someone who is in her first year of the program.  She wanted to know what UX courses were the most useful.

Your user experience coursework is the table stakes.  They’re necessary, but not sufficient, to be a good UX professional.  I won’t point to any of those courses as more or less useful.  Instead, it’s about what you get out of those courses: clear and concise communication, the ability to give constructive design criticism, the ability to take feedback (which won’t always be constructive criticism, but you still have to take it), the ability to juggle a changing schedule, the ability to handle multiple projects and deadlines.  An individual course isn’t make or break — and curricula change all the time, so a course that was useful to me when I got my degrees might not even be offered any longer.  Rather, the gestalt of what you learn during the process of getting your degrees is what will make you a great UX professional.

In many respects, the course that I use the most out of my three degrees is public speaking.  A lot of what I spend my time on isn’t really user experience work.  Instead, it’s communicating about user experience.  I communicate with my UX peers, program management, and application teams to understand what their research questions are.  I formulate a research plan, and then have to communicate that research plan to the stakeholders: why I’ve elected to do this kind of research, what results we can expect to get from this research.  Then there’s actually conducting the research, which isn’t so much about the tools that are used to collect the data (Morae, Excel, Camtasia, etc), but rather how my communication with the research participants as I collect that data.  A good user researcher guides, but does not bias, the participant as the researcher collects data to answer their questions.  After I’ve conducted the research, analyzed the results, and formulated my recommendations, my job is next to communicate the results and recommendations.  And throughout the software development lifecycle, aside from specific research that I have conducted, it’s my job to continue to communicate about previous user research that might be applicable to a given question, as well as general principles of good user experience.

Another unexpectedly useful course, this one from my undergrad, was a course called “statistics and society”.  It was about consuming data.  That course taught me a lot about how to think about data.  How does the method for collection impact the results?  How does the presentation of the data impact its analysis?  Neither this course nor my public speaking courses were required for my degrees, but I think that the skills that I learned in those courses are ones that help me be a great researcher.  I’m able to apply those skills very broadly, and they help me every single day.

Your UX coursework is the beginning.  If you don’t have good UX skills, you’re not going to get very far.  But your UX skills are not enough.  To grow in UX, you need to be great at more than just user experience.

cool girls code

Cool girls code.  It’s one of the awesome t-shirts that VMware is handing out at college recruitment fairs right now.  It can be hard to get credibility as a female software engineer, and that pink shirt is a reminder to all my fellow women in tech that we’re not alone, and that it’s pretty damn cool to be a female software engineer.

Given that I’m out and actively trying to recruit more women to join my immensely geeky company, you can imagine my disappointment when I saw that Violet Blue has, yet again, made an idiotic statement about women in technology.  Actually, she made an idiotic statement about a specific woman in technology.  She attended Macworld 2012, and led off her column with an extended commentary on what she called “the saddest booth babe in the world”.  She even included a picture, which she has since removed, of the woman sitting in a chair looking tired.

The problem, of course, is that the woman in question actually isn’t a booth babe.  The woman is an employee of a small iOS company, not a model paid to draw in foot traffic by showing skin.

It’s hard enough being a woman in tech without some uneducated blowhard, who happens to try to style herself as all about female empowerment, come along and bash a woman in tech by assuming that she’s a booth babe.  I would expect that someone who likes to pretend that she’s a tech blogger would actually know that not all women at a trade show are booth babes.  I’d even like go out on a limb and imagine that this so-called tech blogger could even imagine that a good-looking woman can also work in tech.  It’s especially galling when that very selfsame uneducated blowhard is the one who was bitching last WWDC when some guy asked what she does, instead of assuming that Violet is a developer.  (This is, of course, ignoring the fact that Violet is not actually a developer.  Tech blogger, perhaps, but not a developer.)  At the time, she decided to play the dumb-chick card and pretend that she knows utterly nothing about computers, and then upbraided the guy in her column for falling for her little gambit.

So let me get this straight: it’s bad for a guy to believe you when you say that you don’t know anything about tech, but it’s totally okay for you to call a woman a “booth babe” and complain about her hunched shoulders and “breasts that were packaged air-tight in a tight, branded t-shirt” and not even bother to talk to her?  At least the WWDC guy was trying to make conversation, and believed you when you said that you were a model in town.  Violet Blue couldn’t even be bothered to either (a) go talk to the woman, (b) go look up the development company and see whether she works there, or even (c) not start off a column with such a ridiculous anecdote that had pretty much nothing to do with the rest of her column or the event itself.

I’ve worked Macworld before as a vendor.  It’s freakin’ exhausting.  You’re tired.  Your feet are sore, because you’re standing on a thin layer of carpet over concrete.  You’re quite possibly hung over, a result of having a bit too much fun at the Macworld Blast party the night before.  Your voice is cracking because you’ve been talking too much, answering questions about your application.  That’s the perspective when you’re working in one of the big booths, where you’ve got several of your colleagues around to help out.  But this woman was at one of the teensy developer kiosks, which means that she was probably either alone or maybe had another person there.  That’s also the perspective from someone who just has to drive to San Francisco from Mountain View, so there’s no concerns about jet lag or uncomfortable hotel beds or being in an unfamiliar city and not knowing anyone.

The original picture, which Violet Blue has (of course) yanked, is one that I recognize and identify with.  I’m quite sure that I’ve been seen in that exact same pose at some point in my life at Macworld.  I hope that no-one out there has such an unflattering picture of me, although I wouldn’t be surprised if it were out there.  I’m lucky in that, as far as I know, no-one has chosen to post such an unflattering picture and description of me to a major tech blog.  It’s bad enough to be exhausted at Macworld, I can’t imagine what it’s like to be exhausted and publicly ridiculed there.

As if the original article weren’t bad enough, not to mention the edits done to the article so that it doesn’t look quite so appalling, is Violet’s response.  You see, she got called on her idiocy pretty early.  People who weren’t even at the show took a look at the picture that she posted and figured out that the woman isn’t a booth babe.  Violet, instead of putting her big girl panties on and owning up to her idiocy, instead doubled down:

It’s really reaching to brand me a misogynist because I put the woman in a social category based on the environment she was in. I was not the only one to do so. It was not obvious that the woman in the booth was not a booth babe

It was pretty obvious that she wasn’t a booth babe.  Let me count the ways:

  1. She wasn’t dressed as a booth babe.  She was in pants, a long-sleeved t-shirt, and a short-sleeved t-shirt over that.  Now that I think about it, this is an exact description of what I wore today.  The woman in the booth wasn’t displaying cleavage, she wasn’t wearing platform heels, she didn’t have a skirt cut up to her hip.  There was no skin showing.  Her t-shirt might have been a bit tight, although honestly every t-shirt looks tight when you’re tired and thus not sitting up straight.  But it certainly wasn’t booth-babe tight.  It was just normal.
  2. She wasn’t at a booth that would have gotten a booth babe.  Yes, there were some booth babes at Macworld, but it’s not every booth that gets a babe.  The natural habitat for a booth babe is one of the big flashy booths that are crawling with company representatives, and it’s the booth babe’s job to get people to come to the booth and talk to one of those representatives.  This woman was at one of the little developer kiosks.  They barely have space for two people to be at the booth at the same time.  They certainly don’t have the space for a booth babe, and I bet they don’t have the budget for it either.
  3. Booth babes are never left in the booth alone.  Booth babes are there to get conference attendees into the booth, but then it’s someone else’s job to actually talk to them.
  4. Speaking with her would have made it clear that she wasn’t a booth babe.  Usually, a booth babe can perhaps answer some very high-level questions about the product(s) at hand, like how much it costs and when it will be released.  That’s it: they generally can’t answer deeper questions, and since they’re trying to get lots of people to come to the booth, they’re mostly interested in handing you off to someone else so that they can continue to do the job that they’re there for.

But wait, there’s more!  Then Violet outdoes herself with this:

If you want to know how I really feel about booth babes (though I’m sure you won’t because the drive-by is always better) – get some context for booth babes in my column by reading this:

The CES Booth Babe Problem

http://www.zdnet.com/blog/violetblue/the-ces-2012-booth-babe-problem/963

And you will see that Ms. Szurmai-Palotai is exactly the kind of “booth babe” I am referring to – women devs, women hackers. Not the kind some of you seem to instantly think I mean.

This is completely and utterly ridiculous.  There’s only one definition of booth babe, and Violet’s own CES article is talking about exactly that kind of booth babe: a scantily-clad woman who doesn’t know anything about the technology at hand, but is only there to drive traffic.  No-one has ever seriously tried to refer to “women devs, women hackers” as booth babes.  The term is a pejorative, and we all know it.  Don’t try to pretend that it’s neutral or even positive.

Amusingly, Violet tries to blame the backlash on an “attack” from Daring Fireball, and paints anyone who has criticised her as being a fanboy.  Not so: she had already been called on her idiocy quite some time before Daring Fireball linked to it.  And Daring Fireball’s commentary cannot, in any way, be construed as an attack:

But as Shawn King points out in the comments under the photo, the woman in question doesn’t look anything at all like a “booth babe” — she simply looks like a developer who happens to be a woman manning her booth. And according to subsequent comments by Tim Breen, that’s exactly what she is

Violet says in her comment that she should have been given a chance to do something:

A simple correction would have sufficed, and then you could have seen what I did with it.

The simple correction came swiftly.  And we saw what you did with it, Violet: you did absolutely nothing.  You let your nasty little column stay exactly like that for a day.  It was only after apparently you’d gotten enough comments calling you on your idiocy that you finally edited the column to note that the woman is a developer, and you replaced the original photo of the “sad booth babe” with one of a lineup of iPhone cases.

Strangely enough, Violet’s column about booth babes at CES does get one thing exactly right:

Present an inappropriate female stereotype and – no surprise – you’ll create an environment of inappropriate and stereotypical behavior.

It’s not the booth babes, it’s the reductive booth babe mentality that’s the real problem here.

Yes, it is the reductive booth babe mentality that’s the real problem here.  Now, Violet, take some responsibility for being part of the problem instead of part of the solution.

Q&A: how can I find user experience jobs in the Bay Area?

I’m spending today at the University of Michigan, participating in some campus recruiting.  The morning started off with a networking breakfast with the School of Information, which was great: lots of people who are interested in UX jobs at VMware.  We’re hiring for both summer internships and full-time positions, so this kind of thing is exactly what we need to do to get great hires.

During my talk, I took a lot of questions from the students about working at VMware, what UX is like here, and so on.  Which is great: it gives me fodder for future blog posts.  I’m going to quickly answer one of the questions that I got during that session: how to find UX jobs in the Bay Area.

Working in UX in the Bay Area is truly awesome.  There’s so many tech companies, and lots of them are hiring.  Finding UX jobs can be somewhat of a challenge within tech, because UX jobs can get lost in the general tech hiring that happens.  One great resource for finding UX jobs is BayCHI.  Paid members have access to their Job Bank.  Lots of employers post their UX openings there.  It’s mostly Bay Area, although there are jobs posted elsewhere in California and the US there too.  Many of the jobs are for interaction designers, but researchers and visual designers aren’t left out in the cold.

It’s awesome to see one list of UX opportunities in one place.  It gives you an idea of where the job market is going and what skills are in demand.  For me, although I’m not looking for a job, I still glance over them to make sure that I’m growing my skills in the right ways.  I don’t want my career to stall.  I want to keep improving and moving my career in the right direction.

If you’re in the Bay Area, going to the BayCHI meetings is a great way to network with your fellow UX professionals.  They’re held directly across the street from VMware campus, so it’s pretty easy for me to pop over.  I watch to see what the monthly topic is, and go to the ones that I find interesting.  Most BayCHI talks are excellent, and the networking is icing on the cake.

UX folks: what other resources do you point college students towards if they’re looking for a job?  Other than your own company’s career page, of course.