All posts by nadyne

user experience, VMware

VMware Take 3

1 Comment

One of VMware’s benefits is the Take 3 program.  For those who have been with VMware for at least five years, they can take 3 months off to do something completely different from their usual job.  One option is to work on a different project or try out a different discipline.  Another option is to work with the VMware Foundation and spend 3 months working for a charitable organization.

Deanna McCusker is a UX designer on my team who has been with VMware for 9 years.  She’s on her Take 3 project now, and she’s taking the latter option.  She is working for the Community for Open Source Microfinance on an application called Mifos.  She’s also keeping a blog about her experience, and you can follow along here.

I’ve already informed Deanna that she’s signed up to give a UX tech talk when she’s completed this!

software, women

good jobs vs good husbands

In the New York Times obituary for Yvonne Brill, she is quoted as saying, “Good husbands are harder to find than good jobs.”

I think she’s got a point, although I think that there’s also a difference of expectation between jobs and husbands (good or otherwise).

jobs husbands
can change every 3-5 years generally frowned-upon to change every 3-5 years
can look for a new job while still holding my old job dating while married isn’t generally acceptable
leaving a job needs two weeks of notice and a little bit of paperwork leaving a husband requires (at least) several weeks, a lot of paperwork, and a lawyer
can accept a new position because it’s an awesome opportunity taking a new husband because it’s an awesome opportunity would earn me the label of “gold digger”
can try out something new and go back can’t try out a new husband and go back to a previous one1
a software engineer who has 7 different jobs in the course of their 40+ year career is normal a person who has 7 different partners in the course of their 40+ years as an adult is not normal

windyI’ve got a good husband, and we’ve been married for nearly 4 years.  By Silicon Valley job standards, I should be out hunting for a new one, but I think I’ll stick to societal standards instead of job standards on that one.

  1. Even Liz Taylor, who did marry Richard Burton twice, didn’t have an intermediary husband between her first and second marriage to him. ↩
user experience

on blind design

Alex Griendling wrote an awesome blog post about the predilection of the design community to redesign something that they glance at and decide that they don’t like.  His post concludes with this, which I think applies to more than just design:

Were designers to simply offer their opinions on newly released identities or logos, that’d be one thing. Instead, by offering an opinion and an alternate solution that is presented as being better, we’re disrespecting the designer(s) that made the work while completely ignoring that the piece being critiqued went through the same process that we deal with every day. A little empathy towards work produced and, in turn, the designers that produce said work, would go a long way toward elevating the community’s discussion next time a redesign descends upon us.

It’s important to remember that, when you’re not involved with a project, you don’t know why design decisions were made, what constraints they were under, or what inputs they had to consider.  Coming in as an outsider, criticizing a design, and then presuming that you can create a new design in a day or two in a vacuum is a bad example of the design process, and it sets a bad precedent for all of us in user experience.

Nadyne, women

I’ll be speaking at Women in Advanced Computing ’13

I just got notification that my proposal for Women in Advanced Computing ’13 has been accepted.  My proposal was “The Mid-Career Donut Hole”, and here’s my original abstract (which I reserve the right to revise!):

As a woman in computing, you usually start off being comfortable with having few peers of your gender. When you start out in college, perhaps you had resources available to you like a campus group for women in computing. When you get your first job in the field, perhaps you work for a company that’s large enough to have an organized group for women, or perhaps you just band together with friends for wine and story-sharing.

As you get older, you begin to notice that you have fewer peers of your gender. We know from the research that women drop out of STEM fields in their late 20s and early 30s. There are many reasons for this, and they’re outside the scope of this talk. There are also plenty of women who switch from a technical track to a non-technical track in their career, such as trying out management.

I want to talk about what you can do if you’re in that spot: you’re in your 30s or 40s, and you somehow find yourself the only senior technical woman in the room. I want to address the following questions:

  • How do you stay up-to-date technically?
  • How do you effectively communicate with younger team members?
  • How do you ensure that you maintain credibility?
  • How do you find mentors?
  • How do you continue to grow your career and decide what your next steps are?
  • What can you do to help address that problem of women dropping out of STEM fields?
  • How do you find your peers again?
Q&A, user experience

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.

 

user experience

how to present your results from user experience research

1 Comment

It might just be confirmation bias, but I feel like I’ve been hearing the same question a lot lately: how do you present your results from your user experience research?

I don’t think of the question in this manner.  When you state the problem in this fashion, it presumes that there is one way to do it, and that you do it once and that’s it.  My goal in conducting research is to have it make an impact.  I can do the most awesome user experience research that has ever been completed on any product anywhere in the world by any researcher, and it’s meaningless if it doesn’t actually result in an improvement to the product.  I think that the correct question to ask is, “how do you share the results from your user experience research such that they get acted upon?”

Presenting your research results is never a single task that you do once and never do again.  You will share the results of your research over and over again throughout the development process, regardless of whether the process is agile or waterfall or some mix therein.

The first thing that you should do when you are conducting research is ensure that you have buy-in from whoever you’re going to need it from.  This certainly includes the designer and program manager, and usually includes others as well: additional researchers and designers who are working on related projects, software architects, engineering managers, QA managers, and anyone else who could block the adoption of whatever results come out of your research.

The second thing that you must do is ensure that you and the designer are always on the same page.  After you have conducted the research and are in the process of analyzing the data, you need to involve the designer to ensure that you have captured all of their concerns.  When I am crafting recommendations, I usually create a first pass of them as part of the analysis, and then work with the designer to get their perspective.  In my eyes, that first pass at recommendations is a strawman, intended to kickstart the conversation about what the final results should be.   You want your final results to include recommendations that are the user experience recommendations, not just the user experience research recommendations.  You don’t want a designer to feel like they’ve never heard about an issue until an official results presentation meeting, and you certainly don’t want them to feel like your recommendations don’t meet their design goals.

Likewise, if you anticipate that these recommendations are going to be contentious or will require significant unexpected work, you should discuss the research results and recommendations  with those who are most likely to be impacted by that.  These discussions are usually 1:1, and give you the opportunity to understand other constraints.  If there are major constraints, such as scheduling constraints, you can work in advance to prioritize the recommendations, and work with the designer to come up with a design that addresses as much as possible now as well as a long-term design that will be implemented in the next version.

Once all of this is done, the way that you communicate your research recommendations depends on the needs of your audience. Your communication style needs to match theirs. If they communicate exclusively through their bug-tracking mechanism, then your design needs to be communicated there too. If they communicate via wiki, then your design needs to be wiki-fied. If there’s one stakeholder who really needs to buy off on your design and everyone else will follow that person, then you need to figure out who that stakeholder is and figure out how to get them to buy off on your design. If everyone needs to come to agreement that your design is the one that they will implement, then you probably need to have one discussion with project managers and a different discussion with engineering. Each of those groups have different goals and different needs, so having a separate discussion with each of them means that you’re able to address their unique goals and needs, as well as answer any questions that they might have.

As a part of all of this, you might give a presentation to a roomful of people to discuss your research results, and you might write up a big report and send it out in email.  But that’s not the end of the process.  It’s only the beginning.  You’ll need to share your research results more than once. You’ll need to track the development process and ensure that your recommendations are being acted upon, and communicate with the team if they’re deviating from the recommendations. It might be that they’ve forgotten elements of your recommendations, or that someone new has come on board and simply isn’t aware of them, or they disagree with it and so are conveniently disregarding the research, or (as in every software project that has ever existed) they’re having to make changes to their plan (adding features, cutting features, cutting parts of features, etc), and thus parts of your research recommendations are impacted by those changes. If they’re going to make changes or compromises in the design that you researched, you should be a part of that discussion — you know the design and the research recommendations the best of anyone, and you know why you made the design recommendations that you made, and you can help them make decisions and discuss the trade-offs between development time and user experience.

Remember: no-one cares about your work more than you do. For your research recommendations to be truly effective and fully implemented, you’re the one who’s going to have to track it and make sure that it actually happens.

Nadyne, women

career webinar: “how to map your plan for success and stay on it”

Before I forget … I’m going to be speaking at a Women’s TechConnect webinar on Thursday, March 21, at 8am PT.  The topic is “how to map your plan for success and stay on it”.  The first half of the webinar will be with Stephanie Peacocke, a career coach who will discuss mistakes that people make in career planning and how to pick yourself up if you get off-track.  In the second half of the webinar, I’ll share my experiences in being a woman in a technical field, growing in my technical career, managing difficult career situations, and making decisions about where I want to go in my career.

It looks like they record the webinars as well, so I’ll share a link once I’ve got it.

user experience

Greg Hoy: “good work isn’t enough”

Greg Hoy of Happy Cog has written an awesome blog post about being a great user experience designer: “Good work isn’t enough”.  Greg is right: creating the most amazing designs (and research) isn’t sufficient for you to advance in your career.  You also have to be a good person to work with.  You have to be a good team member.  Greg lists several points of what makes a great designer, including being respectful, being patient, and put in extra effort with no strings attached.

Greg says that this applies to people who ” work in an agency or web department within an organization”, but I think that it’s a lot wider than that.  I think it definitely applies to anyone in user experience, and quite possibly anyone in software engineering at all.