Category Archives: Q&A

your questions, answered

Q&A: moving from technical writing to user experience

I got the following question this week:

I am a technical writer with experience in usability. I do not have a professional degree in design to support my credentials as a UX professional. Is it feasible for someone who is from non-design background to even to get a portfolio considered by the prospective employers?

This is somewhat similar to a question that I answered earlier about moving from engineering to user experience.  In short, it boils down to how you discuss your work to highlight the user experience work that you have done as a part of your technical writing role.

It is certainly possible to get your portfolio reviewed. Your portfolio should show how you have applied your experience and expertise to the problem domain at hand. I recently wrote about what a UX portfolio should contain.  Technical writing can have overlap with UX. It depends on the writer and their experience. Some writers simply interview subject-matter experts and turn that into documentation. Others do much more. Your portfolio will have to explain how your work shows that you understand user experience and user-centred design.

The most important thing to do is to read the job description to determine whether it is one for which you think you would be a good fit.  Then, write a cover letter and resume/CV that explain to the hiring manager why you would be a good fit.  Focus on your UX achievements and accomplishments.  You don’t need to have a specific background to be great in UX.  You do need to be able to explain how your background will make you a great fit for the UX position you want.

Q&A: UX portfolios

I recently was asked by a student what they should put in their UX portfolio.

This is closely related to the question about UX interviews.  Many UX interviews, both research and design, start with a portfolio review.

For a research portfolio review, I want the researcher to answer the following questions about a project that they worked on:

  • What were the research goals of the project?
  • How did they determine the research goals of the project?
  • How did they select the research method that they did?  (Note that “we were told to do a usability study” is a completely valid answer to this question.)
  • What did they learn in the course of doing their research?
  • How did they share the results of their research with the team?
  • What questions were raised by other stakeholders about the research or the results?
  • What action was taken based on the research?
  • Throughout the research process, who did they communicate with, and how?
  • Looking back on the project, what would they do differently, and why?

For a design portfolio review, I look to answer similar questions:

  • What was the user need that the designer was trying to meet?
  • What design ideas did they try as they went through their design process?
  • How, and from whom, did they gather feedback about their designs?
  • What changes did they make to the design as the project progressed?
  • Throughout the design process, who did they communicate with, and how?
  • How did they share their designs with others?
  • What design trade-offs were made?
  • What is the difference between the design and what was delivered?  Why do those differences exist?
  • Looking back on the project, what would you do differently, and why?

These questions scale to the experience of the researcher or designer.  For a student who has limited experience, perhaps working on a project for a semester that might not ever get delivered, will answer these questions differently.  They might not even have answers to some of these questions.  For someone with a lot of experience, I’m much more interested in how they balanced trade-offs, communicated their design, and ensured that their design got delivered.

I’m not necessarily looking for a beautiful design or world-changing research.  When evaluating a candidate’s portfolio, I’m most interested in how their work fit into the work of the rest of their team and how they worked with the team.  Creating beautiful designs that never get shipped is not the mark of a great designer.  Conducting amazing research that never gets acted upon is not the mark of a great researcher.  Being great at user experience is about the user experience that actually gets into users’ hands.  As Steve Jobs said, real artists ship.

Q&A: UX interviews

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.

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.

Q&A: about the use of jargon

In my DevFest talk a couple of weeks ago, I cautioned developers about using jargon.  I got a question about the use of jargon via email, which I’ll paraphrase like this:

I often use jargon when I talk to my customers.  I wanted to show them my IT skills and build trust.  Should I always avoid jargon?

This is an awesome point.  One of your goals when you are talking to users is to build rapport with them.  By building rapport, you make them more comfortable in sharing information with you, and it’s information that you need.

I think that you should use jargon with users, but you need to be careful about it.  You should avoid introducing jargon into your conversation with your user yourself.  You don’t want to lead them to using a term that they know but don’t naturally use themselves.  You want to hear the term that they naturally use.  If you hear that enough people don’t use the jargon that you use, but instead use something else, you might want to change how you refer to this item to match their own terminology.

You should listen closely to how they refer to something.  If they use jargon to refer to that thing, use that same jargon to refer to the same thing.  Be careful to ensure that you understand exactly what they mean when they use that term.  One of the examples that I gave was in the case of looking through log files: “event”, “alarm”, and “alert” are often used in log files.  Different log files use those terms in very different manners.  I’ve seen log files where “event” meant “something very bad has happened”, and I’ve seen log files where “event” meant “something has happened; could be good, could be bad, could be neutral”.  If you were talking to users about troubleshooting and they used the word “event”, you should clarify with them what “event” means to them to ensure that you are using “event” in the same way that they are.    If you assume that you’re using “event” in the same way, but they mean something different than you do, you could make erroneous inferences based on that misunderstanding.


Q&A: does the sexism in CS ever get better?

I saw this question on Geek Feminism a couple of weeks ago, and I don’t feel like I’ve come up with an answer that is satisfactory yet.  The question is in parts, so I’ll tackle them one at a time.

If you’re a woman in CS, does it ever get better? If it got better for you, where and how did that happen?

Dan Savage and his husband Terry Miller famously told gay kids who are being bullied that it gets better.  Their video inspired thousands of others to film their own videos, ranging from all sorts of individuals to the San Francisco Giants to President Obama.  If you’ve watched a lot of these videos, you can often boil their message down to a few points:

  • A lot of homophobia is rooted in ignorance and immaturity.
  • When you’re the only LGBT person that you know about, you feel completely alone.
  • When you’re in a situation where you’re surrounded by homophobia, sometimes the only solution is to get the hell out of there.
  • Once you get the hell out of there, you have to find someplace that is accepting of who you are.

I think that there are a lot of parallels to the sexism that exists today in computer science and software engineering.

A lot of sexism in CS is rooted in ignorance and immaturity.  As men start seeing more accomplished women in CS, it gets better.

When you’re the only woman around, you feel alone because you have experiences that aren’t shared by others.  It gets better when you find another woman who is in a similar situation who you can talk to — it lets you know that you’re not alone.

If you find yourself in a situation where you can’t handle the sexism that you’re dealing with, sometimes the only solution is to get the hell out of there.  I know that finding a job isn’t trivial and isn’t something that you do overnight, but then those LGBT kids have to wait until they’re 18 so that they can leave home too.  Polish up your resume and portfolio like they’ve never been polished before, start applying for jobs, and get the hell out.

As you’re looking for a new job, remember that the interview is a two-way street.  A couple of months ago, I wrote a long post about participating in an on-campus interview, and my last point was that you should ask questions about what’s important to you in your position.  If you’re getting the hell out of a job because of the sexism that you’re dealing with, you should have a lot of questions about the team and its culture.  Obviously you’re not going to ask, “so, how many sexist pigs do you work with?”, but there are plenty of questions that you can ask and observations that you can make that will help you understand what the situation there is like.

If you’ve learned to deal with it, how?

As ever, it depends on the sexism.  Frankly, it also depends on you, too.

Sometimes you simply call ’em on it.  How you do it depends on the situation and your relationship with those involved.

For example, one day, I was working in my office with the door open.  A bunch of male engineers who I know pretty well were standing in the hallway chatting.  One of the guys, who is single, commented that he always felt like he was behind on stuff: keeping his apartment clean, doing laundry, etc.  Somebody said, “oh, you need a wife!” and the rest of the guys agreed vociferously.  I got up, walked to my door, and simply stood there with an eyebrow raised.  The single guy laughed and said that it wasn’t his idea, and the others backpedaled, including a couple who said that they’re also married to women who work in tech and that it’s a lot easier to manage when you’ve got two people to handle everything.  I didn’t say anything, I certainly didn’t call them sexist, and it ended up being a funny anecdote for all of us.

Sometimes you work on it over time, and you build up your credibility so that the sexist behavior fades away.  Credibility goes a long way towards fixing sexism that’s rooted in ignorance.  I’ll admit that I’ve laid the smackdown on someone who tried to mansplain to me that the problem that we were discussing was NP-complete and what that meant.  As if the mansplaining wasn’t obnoxious enough, he was totally wrong about it being NP-complete — in fact, it was only O(n²), and I proved it.  He wouldn’t meet my eyes in the hallway for weeks afterwards, but a few months later, I heard through the grapevine that he had complimented my technical skills in a meeting.

One thing that you always always do when combating sexism is to be the change that you wish to see in the world.  Do not display any sexism yourself.  For example, don’t use your mom (or the more generic soccer mom) as an example of a non-technical user.  I don’t care if your mom really isn’t technical.  It goes without saying that you should avoid other stereotypes, -isms, and -phobias as well.  Don’t display racist behavior, don’t display homophobic behavior.  Your credibility in trying to address sexism is negated when you make a racist comment yourself.

If being ostracized and viewed as gross and weird for being feminist and female “never gets better,” why stay in CS?

I reject that it “never gets better”.  It might not get better in certain situations.  Buy me a cocktail sometime and I’ll tell you about the manager who wanted to know when I planned to get pregnant so that he could include it in his schedule for our next release.  I doubt that he’s ever going to get better.  But you can find situations where it is better, and you embrace them, and you try to make it better for other women too.

Even in a bad situation, one of the reasons that you stay in CS is because you love it.  If you don’t love it, and if it’s a bad situation, you don’t have a good reason to stay.  This isn’t to say that sometimes the sexism just gets overwhelming and you can’t take it anymore, and so you do go off and do something else.  If that’s the decision that you make, that’s valid.  There have been some pretty nasty examples out there.  If I try to put myself in those shoes, I’m not sure if I wouldn’t’ve walked away myself.  But, thankfully, I haven’t been that unlucky with sexism in CS.

I think that it’s incumbent upon technical women to make ourselves available for mentorship.  It’s hard to find a technical woman for a mentor, especially ones who have been in tech for several years.  So for those of us who have, I think that we should help out the younger women who are experiencing a lot of the same things that we did, and hopefully helping to avoid having women drop out of the field because they just can’t take the sexism any longer.  I do this at VMware, mentoring some of the younger women on my team1 and reaching out to them when I think that they could use a hand.  It’s also one of the reasons why I write this Q&A series of blog posts, to exemplify the behavior that I think that a senior technical woman should have.

Ultimately, I think that the way that sexism in CS gets better for us as individual women in CS is to find your tribe.  Find the other women who have walked the same path that you want to walk.  Find the men who aren’t sexist.  Find the courage to get yourself out of a bad situation.  It gets better, and it requires you to help make it get better.

  1. Men aren’t left out. I’m currently mentoring the newest researcher on my team, who is male.

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.

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.

Q&A: a day in the life

I’m coming up on six months with VMware (!!!), and it seems that life is settling down into routines.  I recently got asked what life is like as a researcher at VMware.

I’m currently actively working on three different projects:

  • Zimbra web client usability study
  • vCloud Director contextual inquiry
  • vSphere/vCloud/more longitudinal research

Today, I’ll have a bit of each of these.  As of this writing (10am), I’m anticipating that most of my day will be spent split between vCD and Zimbra, but we’ll see what happens.

I take a combination of Caltrain and VTA to get to work.  VMware pays for all of my public transit costs, it only takes a few minutes longer to get to work than it does if I drive, and it’s a great excuse to buy a cup of coffee at Red Rock on my two-block walk to the train station.  What’s not to like?

I usually don’t have meetings on Monday mornings, and today is one of those Mondays.  The morning starts off with email.  I’m one of those Inbox Zero sorts, so the first order of the day is getting as close to that as possible.  A few of the items in my inbox are things that will get handled as I go through my to-do list for the day, so I leave them there for now.

First order of the day is to get ready for a Zimbra usability study that I’m running next week.  Most importantly, I need to start to recruiting participants, so I spend the morning putting together a survey to find participants that meet my criteria (in short, they regularly use email, calendar, and address book for business purposes).  Once that’s sent out to some potential participants, it’s time for lunch.

After a VMware cafeteria lunch of aloo gobi and a samosa, it’s time for another email check and a couple of steps closer to Inbox Zero.  A couple of the mails that I received were from Bugzilla.  I submitted some fit’n’finish bugs for one of our applications late last week, and I got some questions about those today.  I spent a half-hour doing a bit more research and getting screenshots to further illustrate the issues that I observed.  I’m pleased to note that a couple of the bugs that I had submitted were pulled into an earlier release than I had previously requested.

Just as I wrapped that up, one of the interaction designers on my team popped by my office to ask a question about the survey that I’m using to screen participants for the Zimbra study.  We had a quick chat about the study, my goals for the study, and what kind of participants I’m interested in.  He was especially interested in the difference between two questions that I asked and how that differentiates between potential participants.  I opened up the survey results to date and quickly showed him some of the anonymous results to help him understand what distinction I’m drawing and why it makes a difference.  (Sorry, I can’t say more about this without disclosing too much about the study!)  I love having such an extensive user experience team who are highly invested in what’s going on, even when they’re not involved with the project that I’m currently working on.  It’s such a great environment.

Then it was part of the non-sexy part of being a user researcher: doing all of the work necessary to run the usability study.  I checked out the usability lab to make sure that I’ve got everything I need there (and grabbed a picture of the VMware turtles, who were out sunning themselves when I walked past their pond).  I also spent some time getting a couple of test accounts set up, sending mails to those test accounts, and populating the calendar.  I even pressed a few members of my team into service and got them to send mails to my test account, so that not everything is coming from me.

With that done, I spent some time prepping for the vCloud Director research that I’m kicking off.  I worked on the discussion guide for the study, and sent off a flurry of mails about getting participants scheduled.

I wrapped up my day with my weekly 1:1 meeting with my manager.  We talked about my upcoming projects, the open positions that we’re hiring for, and some ideas for future research directions.  Then I came back, made it all the way to Inbox Zero (yay!), finished up this post, and caught the bus home.

Q&A: moving from software engineering to user experience

Via email, I received the following question:

I am interested to know how you made the transition from being a software engineer to UX researcher?

My background is a technical one.  I have a BS in mathematics and another in computer science.  I’ve been a developer, including some VAX assembler.  I’m reasonably comfortable in Xcode, even though I don’t really code these days.

I don’t think that moving from a development role to a user experience role is a difficult change to make.  As with any kind of job hunting, it’s about finding the right team that will value the skillset that you have.  Not all teams will find such a background useful, but there are many that will.  I think that there are several unique skills that someone who is currently a developer can bring to the table.

Technical skills are quite useful when you’re considering the user experience and brainstorming potential solutions to issues.  Your potential solutions will consider what’s possible and thus have an increased probability of having an impact on the product.

Having technical skills and user experience skills can help bridge a communication gap.  UX professionals sometimes don’t have a technical background, and developers sometimes don’t have a UX background.  Being able to speak both languages is a positive asset.  I’ve seen several cases where the UX team and the development team were both talking about the same thing, but getting frustrated with each other because they didn’t realise they were doing so.

There are a lot of UX problems to be solved on applications that are complex and deeply technical.  They might not be as sexy as working on the new social media hotness1, but they do have an impact on a lot of people and a lot of multi-billion-dollar corporations.  In my opinion, technical skills help in getting up-to-speed on deeply technical applications.  For example, I worked on DB2.  Understanding databases and knowing SQL helped me immeasurably in that position, and meant that I could hit the ground running.

Another potential positive aspect of being a developer is having experience in shipping applications and continuing to support them after their release.  Understanding the software development lifecycle from deep in the trenches means that you have a great understanding of when various types of research will have the greatest impact on the application.  This helps you formulate the right research plan to answer the right questions at the right time.  A development background isn’t the only way to reach this understanding, but it’s a great way to get there.

It goes without saying that having development skills isn’t sufficient to move to a UX position.  You need to be familiar with UX methodologies, and ideally you would have examples of applying such methodologies in your development work.  You also need to display excellent communications skills, since so much of UX isn’t so much about applying the right methodologies as it is about communicating with the application teams and influencing them to make changes based on your research and recommendations.

As a developer, you can set yourself apart from the competition if you can show product impact, and discuss how your unique skillset of both CS+UX helped you have a significant impact on your product.  Changing roles within the software industry happens frequently; I think it’s to be expected that people in many disciplines within software engineering will want to try out new things.  As I was thinking about this question, I came across an article about moving from engineering to product management; a fair amount of the advice in there is applicable to a move from engineering to UX too.

In other words, if you want to make a change, get out there and find the right position for you.  I don’t think that finding the right position in this case is any harder than finding the right position for anyone who is looking for a software engineering position that is outside the norm.  After all, there are many more web developer jobs than there are UX jobs.  You’ll also find that, within UX, there are more design jobs than researcher jobs.  It’s rewarding once you find the right job, but getting there can be frustrating and time-consuming.

  1. Nothing against social media.  After all, I’m active on twitter!