Category Archives: Nadyne

women

Maria Klawe on impostor syndrome

Maria Klawe, president of Harvey Mudd College, talks about impostor syndrome in Impostoritis: A Lifelong, but Treatable, Condition.  I like this paragraph the best:

Now I wake up most days with a voice on the left side of my head telling me what an incredible failure I am. But the voice on the right side tells me that I can change the world—and I try to pay more attention to it. My life goal in changing the world is to make the culture of science and engineering supportive of everyone with interest, ability, and willingness to work hard, independent of race, gender, sexual orientation, other interests, or anything else. For that to happen, we need more women, people of color, poets, artists, ballroom dancers, and football players to enter, succeed, and persist in all areas of science and engineering.

I like that she discusses not just entering the field, but succeeding and persisting in it.  We’re still losing so many people after 10 years in the field.  It’s got to stop.

Q&A, user experience

Q&A: Good websites for user researchers looking for a job

On Quora, someone anonymously asked me to answer this question:

What are the best job boards or professional organizations with job postings, specifically for User Researchers?

I’m not sure that there is a best job board for User Researchers. There are many fewer jobs for researchers than there are designers, which makes finding positions more challenging.

For positions in the San Francisco Bay Area, BayCHI is an excellent resource. You have to pay for a annual membership to get access to its Job Bank, which is well worth it.  BayCHI also gets some job postings for companies who are headquartered in the Bay Area (or have a significant presence here) but are looking for people in other locations. BayCHI covers all of user experience, not just research; my unscientific glance over the past few weekly emails says that 10-20% of the job ads posted there in any given week are for researchers. Also, the monthly BayCHI meetings are good places to network, which might be an even better way of finding out about a position.

On Twitter, there are a few UX job aggregators. The one that I’ve found with the most researcher jobs is @UXdesignjobs.  It, like BayCHI, does not focus on UX research jobs, so you will have to filter out the design jobs that aren’t relevant to you. They do have a good mix of jobs at US companies.

A good Glassdoor search can also reveal appropriate user researcher positions, and they will automatically email you with new ads posted that meet your search terms. Glassdoor shows more jobs outside of the Bay Area. A good search is more likely to result in user researcher jobs; a few non-research jobs still sneak in. In general, the jobs that show up on Glassdoor are at larger companies, and their daily email can be repetitive.

Since you asked, I will note that my team at VMware is hiring user researchers.  You can ping me directly if you’re interested in this role.

I’m not aware of a great job posting site for UX positions outside of the US. Perhaps someone else can share insight there.

I’ve generally found that having a robust LinkedIn profile is an excellent method for getting approached by recruiters. This might be a Bay Area bias showing, I’m not sure how pervasive LinkedIn is outside of the Bay Area. I do regularly get contacted by recruiters on LinkedIn from outside the Bay Area. I sometimes hear from recruiters who don’t get the difference between UX design and UX research, and I occasionally get recruiters who see “researcher” and think that I’m conducting scientific research. Overall, though, I think that my LinkedIn profile is one of the most useful tools when I am looking for a job.

Nadyne, user experience

on letting go

When I first started at VMware, I noticed that there was my User Experience team (about 25 people at that time, working mostly on vSphere and related applications), and that there were several individual interaction designers sprinkled throughout the company.  I proposed that we all get together, and eventually, a two-day internal UX conference was born.  I chaired it the first year and the second year.

Then I had to let it go.  I explicitly said this to my conference committee, as well as my management, as I was working on it for the second year.  This conference couldn’t just be my thing.  If it was to have any legs, it had to become a VMware thing.  So, vUE 2014 planning kicked off, and I am not part of its conference committee.  I provide whatever assistance they ask me for, but I’m explicitly not part of the conference committee.

I did a lot to try to set up the future iterations of the conference for success.  The first year, I did pretty much everything, with assistance from a small conference committee.  The second year, I made some changes to the conference committee: I broke up the work into Conference Chair and Technical Chair (following the model used by many academic and industry conferences), and I made sure to choose my successor so that she could learn as much as possible from me.  I was also aware that I was setting precedents, so I was very careful about what I chose to do (or not do).

Letting go is hard.  I have a big investment in this conference.  But it can’t be mine.  It has to become something that VMware’s UX community owns.  From the outside, they seem to be doing a fine job.  It’s a bit odd to see the announcements coming out about the theme and how to submit papers and not be the one who sent them.  I’m sure it will be even more strange to attend the conference as an attendee and not as its conference chair.

I’m so glad to see it continuing forward without my involvement.  This tells me, more than anything, that it was truly something that VMware needed and continues to need.  It tells me that it’s something that the VMware UX community values.  It tells me that UX at VMware is vibrant and growing.  It tells me that it was the right thing to do.  I know some of the evolution that it has already undergone with new leadership (some that I anticipated and tried to make sure things were set up so that it could evolve in that direction, some that I never anticipated), and I’m sure that I’ll see more evolution when the event itself arrives.

user experience

when user interviews go bad

The Cranky Product Manager asks what to do when you’re stymied when interviewing a user.  In her example, she asks a broad question, and the user responds with a list of details that they want fixed in the application.

I think that scenario is familiar to everyone who has ever tried to interview users.  I usually handle this situation by reviewing the list and trying to understand what brought us to the point where this is the interaction that the user wants to have with me.  Are there items on their list that are so important to them that these items block them from being able to consider anything else?  Are there categories of problems on their list that tell me that there’s a bigger problem to solve here?  Are they trying to accomplish a workflow that we didn’t consider or didn’t get right?  Is the overall problem one of death by a thousand papercuts?  If I can identify a trend in their list, I can make more headway in making user experience improvements that go beyond filing 23 bugs.

Another option in handling this is “tell me more”.  “Tell me more about item #3 here.  Can you show me what happens?”  This gets them talking about the context of item #3, and puts it in perspective of what they’re trying to accomplish when they run into the problem that they’ve identified that they want you to fix.  It can give you the insight that you need to address the underlying problem.

When you receive a list like this, you must be open to the feedback that you get, analyze it carefully to understand what the problems are, and make informed decisions about the next steps to take (which might or might not be doing exactly what is outlined by the list).

user experience, vSphere

“why I like the vSphere web client a lot!”

I missed this post over the holidays: “why I like the vSphere web client a lot!”  There’s a couple of things in it that are near and dear to my heart, such as Mac support1, Works in Progress2, and tags3.

  1. I’ve been advocating for this ever since I joined ↩
  2. Internally, we still call it by its original name, TIWO (tee-whoa): Things I’m Working On. ↩
  3. My first major research project at VMware was about tags. ↩
Nadyne

San Francisco and wage disparity

There’s been a lot of attention in San Francisco about wage disparity, ever-increasing rents and housing values1, and the attitudes about them.  It’s very easy to see it play out in person if you live here.

From the sidelines, you can see it in the press.  Take two pieces from the San Francisco Chronicle, written just a few days apart:

‘Techie’ term draws derision from tech workers, in which tech workers2 complain about being called “techie” by non-tech workers, and non-tech workers complain about the behavior of tech workers.  (This article has an amazing example of the blinders that tech workers can have about their position here, where one self-identified entrepreneur said, “Whenever you get a mass migration of a new wave of people, you get a negative connotation from the people who were there before – like Mexicans in the Mission. The new wave always gets a bad rap.”  I really can’t accept that highly-paid tech workers can be reasonably compared to mostly low-wage manual laborers.

Protesters block Google bus in S.F. Mission, in which local advocates protest the use of public bus stops by private buses shuttling employees from San Francisco to Silicon Valley tech companies.  The latter incident has spurred much discussion amongst tech bloggers.  There have been some pretty reprehensible posts written about it.  It was hard to choose the worst of the lot until a poorly-written piece on Pando labeled as satire came along.

Jason Calacanis has written an excellent response to this, in which he points out that “[a] society can best be judged by how the most privileged regard and treat the most vulnerable and weak”.  I agree: I think it’s incumbent on those of us who have been lucky enough and privileged enough to have our skills valued so highly consider how we can make our communities better places for all of us, not just those who can afford an ever-increasing cost-of-living.

  1. Which is generally good if you’re already a homeowner, but much less so if you’re an aspiring homeowner. ↩
  2. Yes, you can see my bias here ↩
Apple, user experience

consistency matters

2 Comments

There is an inconsistency in two things that I use frequently, and it trips me up all the time.

In OS X Mavericks (and previous versions1), when using the Finder, there’s one keyboard shortcut that I use all the time.  If you have a long list of folders and files, you can go to the parent folder and type the first letter of the file that you want.  It will jump to the first file that starts with that letter.  I have lots of folders with lots of files in them, and I use this all the time so that I don’t have to scroll.2  For example, if you have a folder with a lot of files in it, and you want to jump to “nadyne.txt”, you can select the parent folder (say, Documents) and then type an N.  You’ll be taken to the first item in the list with an N, and have much less scrolling to do.

However, in iTunes 11, if you want to jump to the first item in the list that begins with an N, the focus has to be on the list itself.  For example, if you want to jump to “Neko Case” in your artist listing, you have to have focus there, and then click N.  To be consistent with the Finder, you would need to have focus on the parent object of “Music”.

I don’t really care which behavior is the winning behavior, I just wish that the two were consistent.  I trip over this all the time, and it drives me utterly batty.  (And yes, I’ve submitted the Radar: 15750167.)

  1. I can’t say how far back.  Muscle memory says that it’s far back indeed. I can’t remember when it didn’t work this way on OS X. ↩
  2. I use this even more frequently now that the arrow buttons have disappeared from scrollbars, but that’s another post for another time. ↩
career

thoughts on career fairs

Career fairs are hard events.  They’re hard for me as someone who is there to evaluate candidates to fill positions that my company has open, and I certainly remember them being hard when I was in college and looking for a job.  Now that I’m on the hiring side of the table, I want to share with you some of what I’ve learned that might help someone on the please-hire-me side of the table.

At most career fairs, the employers are going to speak to dozens of candidates.  At some of the larger engineering career fairs that I’ve attended, we have walked away with hundreds of resumes.  That’s just one career fair at one university.  Now imagine how many career fairs our University Relations staff go to.  (For us engineers, we usually only go to one or two career fairs per year.)  We get a lot of resumes out of these, and we have to figure out which candidates we’re going to call back after we’re done with our career fairs.  Here are some things to do to stand out at a career fair.

  1. Spend the time now to get your resume into great shape.  Your resume represents you.  It should be clear, well-written, and underscore your unique combination of education and experience that makes me want to hire you.  If your university has any resume-writing resources, take advantage of them.  If not, get your friends and a trusted faculty member to review your resume.  A resume that has typos in it says that you don’t pay attention to details. A resume that lists every single Computer Science course that you’ve taken does not tell me why I should hire you.  A resume that says that you play intramural lacrosse makes me wonder why you think this is something that you want me to know.
  2. Tell me whether you are looking for an internship or a full-time position, and when you are available for this position (summer internship? full-time position starting in September?).  It saves me from having to scan your resume and guessing.
  3. Explain why you are a great candidate to work at VMware.  This tells me that you’ve done research on my company, which is always a good start.  You should tell me what from your background matches up with goals for my company.  Even better is if you’ve looked at some of our open positions and can thus reference skills that we often look for.  Also make sure that you look at our locations.  You should know the location of our headquarters and our other primary offices, and you should be comfortable with living in one of those places.
  4. I’ve got a standard spiel that I have ready to go for candidates at career fairs.  I’ll tell you about the company, where we’re located, what kind of work we do, why it’s awesome to work here, what kind of career opportunities we have, what our internship program looks like, and so on.  A candidate who already knows all of that, and we can get into details about why you would be awesome for us and who has specific questions for me about why they should come work for us is a candidate that is more likely to get my attention at a career fair.
  5. You should talk positively about your experience so far.  If you can take something difficult and tell me what was positive about it (“I learned a lot about how to handle uncomfortable situations with others in our group project when one of the team members was unable to meet their commitments”) makes me think that you’re resilient and can solve problems.
  6. Talk to your professors, your department administrator, and professional campus groups about companies that will be visiting.  For example, when I visit a campus for a career fair, I’ll often give a talk to a department or a class that is relevant to the user experience jobs that I have open.  You’ll have an additional opportunity to talk to me, it’s usually a smaller setting than the big career fair and so you have more time to make a positive impression on me, and you’ll learn more about the company and the work we do.

Here are some things that reduce your chances of being successful at a career fair.

  1. Ask me what my company does.  I’ll tell you (as I said, I’ve got that standard spiel), but this tells me that you didn’t do any research before you walked up to me.  You’ve lowered my expectations about you, and you’ll have to work harder to convince me that you’re a great candidate.
  2. Be unsure about what you want out of an internship.  It’s valid to say that that you’re exploring options, but that means that you should be able to tell me what kinds of questions you have about software engineering careers and how you think an internship will help you answer them.
  3. Start off by telling me that you don’t use my company’s products.  Since I work for an enterprise software company, I don’t expect that candidates at career fairs will have experience with our products.  Instead, tell me why you’re interested in working for a company that makes enterprise software.  (While “I really need a job” is an answer that’s probably true and I certainly remember that feeling, please come up with something better.)
  4. Don’t stuff a resume in my hands, ask for a t-shirt (or whatever other swag we’re giving away at that career fair), and then leave without talking to me.  That resume goes to the very bottom of the pile.  If you really don’t want to work for my company and just want a t-shirt because free clothing is a good thing when you’re in school, come around at the end of the career fair.  If we’ve got extra shirts at the end of the career fair, we’re pretty likely to give them out to anyone who asks, so that we don’t have to ship them back to the office.
  5. Don’t assume that talking to a woman means that you’re talking to someone who isn’t technical.  It’s perfectly okay to ask what I do.  Assuming anything about me, or any of my colleagues who are working with me at the career fair, tells me that you’re likely to make assumptions in the work that you do, too.  Invalid assumptions cause lots of problems in software development (“no-one will ever enter invalid data here” is the root cause of many bugs).  Doing this leaves me with a very bad first impression of you, and since our time to talk at a career fair is very limited, that very bad impression is likely to stick.
  6. Don’t have any questions about what it’s like to work at my company.  Remember, this isn’t a one-way interaction.  It’s not just about the company deciding whether they want to hire you.  It’s also about you deciding whether you want to work for the company.  As we talk, you should ask follow-up questions if there’s something that you hear that you want more details about.  You should also have questions about the company, the team, the product, or the working environment.  Not having questions tells me that you’re not necessarily as interested in working for my company as other candidates who did ask me questions are.

Our interaction at a career fair is limited.  There’s a lot that you can do to make that interaction very positive.  The more positive that interaction is, the more likely you are to move forward.

user experience

how to benchmark UX

One of the LinkedIn groups that I’m subscribed to, Mobile UX, asked a question about how to benchmark UX.  This is something that we do at VMware, and that I did during my time at Microsoft too.  The methods at both VMware and Microsoft were reasonably similar.

My team has two different methods that we use to benchmark UX: scorecards and baseline studies.

Scorecards are during the product cycle, and rate the user experience of the top use cases. Scorecard studies can be repeated at any time during the development cycle, and allow the team to see progress being made (or not!). We use different methodologies for scorecard studies, depending where we are in the development process and what the resources available are. Scorecards are generally qualitative in nature. The goal is to provide an at-a-glance view of our current UX, with additional details about how to address any UX issues that might exist or what is currently being done about it (say, a link to a bug that has been opened to track a particular issue).

Baseline studies are conducted on the completed product that ships. Baseline studies are quantitative. Participants have a task list which they are asked to complete without thinking out loud. Our important metrics here are time-on-task and success rates. The task list for the baseline usability study is based on the most important use cases for the product, and is intended to be repeated on each subsequent product release.  A baseline study can help you determine whether you met your UX goals for this release.  It can also identify places where you unintentionally had a positive or negative impact on your UX.  Trend data over multiple releases helps others understand the ROI of UX.

I’ve also used baseline studies to help teams understand the usage of their application better.  When an application or team has never had involvement from UX before and isn’t sure how to best use this new UX resource, a baseline usability study of the top use cases often makes it clear where UX should focus their time and attention.  If you learn in your baseline study that your users have trouble completing one of the most important workflows in your application, you know what you’ve got to fix.

I like benchmarking UX to be able to show where we came from, how we got there, and what we learned along the way.  I especially like being able to show where we are today, since it usually illuminates at least part of where we need to go tomorrow.