Category Archives: Nadyne

Nadyne, women

prepping for a talk

I mentioned that I’m giving a talk this week at Women in Advanced Computing 2013 titled “The Mid-Career Donut Hole”.  I started out with the idea that there is a hole in the middle of your career, that hole is where women are the most likely to drop out of a technical career, and that there are steps that we as individual technical women can take to make it less likely that we and others drop out of technical careers.  With that idea, I wrote up an abstract and submitted it to speak at WiAC.

I’ve had the idea in the back of my head for months.  Ever since that idea arrived, I’ve been jotting down notes that are related to it.  As I’ve read books and articles, and they’ve led me to think about the topic more, I’ve fleshed out more of what might be included in the talk.  When I got the notification that my proposal had been accepted, I began working on it in earnest.  I first started looking at my notes and creating pieces of the talk, figuring out what would work and what wouldn’t work.  In working on those pieces, I spent a lot of time talking to myself in an empty room, to see if those pieces sounded good and felt natural when I talked about them.  Some things didn’t survive this cut, others were changed dramatically from their starting point.

When I felt like I had enough pieces that sounded right, I had to figure out how they fit together.  I had more pieces than I had time, but that’s okay: some of those pieces didn’t work in the context of a larger talk.  Some got cut, some got condensed.  New pieces got added when I discovered that I needed a bridge from one topic to the next.  I went from pieces that were related to this idea to a something that I hoped was a single cohesive discussion.

When I thought that I had the whole thing done, I stood in an empty conference room and gave the whole talk from start to finish.  This helped me be more comfortable with the talk as a whole, as well as identify places where it didn’t flow well.  More cutting ensued, as well as some new additions.  I tried again, felt more comfortable with it, and then rounded up a couple of colleagues to give me feedback on it.  They gave me fantastic feedback, which resulted in more revisions and more practice.

The talk is Thursday morning, 11am.  I really want to get this one right.  I’ll let you know how it goes.

user experience

a quick test of your product

I read a great blog post about cognitive overhead, and it reminded me of one of the simplest pieces of user research you can do on an established product.  I’ll quote the article:

Let people use your product, and then ask them to tell you what it does. They’ll think you are crazy for not knowing already, but what you hear can point to cognitive hurdles you’ve missed.

This is an awesome way to get some fantastic data about how your users see your application.  If their answers surprise you, either because they talk about things that you don’t think are important, or they miss things that you think are essential to your product, then you’ve got some problems that you need to address.

Nadyne

how to update your resume

I have to admit, I’m seriously tempted to update my resume with some of these phrases from Design Jargon BS.  Or maybe just keep them in mind for my next meeting.

  • “Ensures focus and consensus whilst encouraging maximum creative flexibility across multiple touchpoints”
  • “Develop a deeply cohesive BrandWorld where all transmedia applications connect effortlessly”
  • “Our digital dept may actually be made in binary. They eat, sleep & drink digital then regurgitate it into information”
  • “Messaging that emanates from organisations synonymous with communications that denote direct unequivocal propositions”

I have to stop now, otherwise my brains might leak out my ears.

user experience

on being senior

John Allspaw wrote a great blog post titled On Being a Senior Engineer.  I read it, nodding along, and realized that his post isn’t really about being a senior engineer.  As Allspaw puts it, “I expect a ‘senior’ engineer to be a mature engineer”.

He’s totally right.  A senior engineer, or a senior user experience professional, or (I think) a senior anything is about maturity.  It’s not just about the number of years that you’ve worked with a given technology or done a particular job.  It’s about how well you get your job done.  These items from his post particularly resonated with me:

  • seek out constructive criticism of their designs – When you’re senior, you know that your work isn’t automatically perfect.  You know that others have valuable perspectives, that they have knowledge that you don’t have, that others can be the source of a valuable insight that you wouldn’t get otherwise.
  • understand […] how they are perceived – Allspaw said it well here: “Mature engineers know that no matter how complete, elegant, or superior their designs are, it won’t matter if no one wants to work alongside them because they are assholes.”  Oh, and this too: “Be the engineer that everyone wants to work with.”
  • understand that not all of their projects are filled with rockstar-on-stage work – There’s a lot of work to get done.  Being willing to do the work that needs to get done, not just the high-profile work, is one of the ways that you become senior.  This is related to, but definitely not the same as, being the person who everyone who everyone wants to work with.
  • lift the skills and expertise of those around them – One of the most important things that you can do in a senior role is to help your team be better. If you’re the rockstar on your team, but everyone else around you is floundering, you’re not senior.  You need to help those around you so that they can be rockstars too.  Create a team of rockstars, and that’s one of the ways that you become senior.
  • make their trade-offs explicit when making judgements and decisions – Nothing is perfect.  Life is a balancing act.  When you’re making trade-offs, document them.  It will help others understand your thinking, which makes the team better and which helps with gathering constructive criticism.  It will also help yourself in the future so that you remember why it is that you decided on one thing over another.

Allspaw makes a lot of other awesome points, and I feel like I’ve lifted enough from his post as it is.  His blog post is one of the most insightful and thought-provoking that I’ve read in quite some time.  It’s long, but I recommend reading all of it and thinking about how it applies to your career and your life.

user experience, VMware

VMware User Experience 2013

In November 2011, I led VMware’s very first internal conference for its user experience community, with the creative title VMware User Experience (vUE).  VMware’s user experience community is spread across the whole company.  There’s my team, which works on the vCloud Suite and related products.  There’s a few other small user experience teams across the company, in places like Customer Advocacy and Socialcast.  And there’s a lot of interaction designers who are embedded with their teams, one or two people sprinkled here and there throughout the company.  Our goal for the first vUE was simple: get everyone together for two days and get to know each other.  We ended up with 60 people attending, representing a diverse array of products, with people coming from as far away as Sofia, Bulgaria; Herzliya, Israel; and Sydney, Australia.

After vUE 2011, we instituted some new practices to help our user experience community keep its momentum going.  I created and am leading a series of UX tech talks, in which we as a community come together and share our experience and expertise about user experience.  The UX tech talk series isn’t limited to just user experience people, and we usually get ~100 people attending each tech talk.  We also have a monthly UX all-hands meeting, which is led by one of our Directors of User Experience at VMware, and gives us an opportunity to share things that are of interest to the whole community.

I’m also chairing vUE 2013 1.   We’ve had the opportunity to meet each other, and we now have other ways to keep in touch and be able to share our expertise.  This time, our goal is to build upon all of that, and talk about ways that we can improve the user experience at VMware.  We have 22 UX people across the company who are going to give technical talks (10-20 minutes each) about a topic that they’re passionate about, and we have several invited talks, including each of our Directors of User Experience as well as members of our executive team.  We’re also having breakout sessions to give everyone a chance to dive deeper into specific topics, and the all-important social event to share cocktails and swap stories of user experience.

vUE 2013 is five weeks away, and we’re wrapping up all of the final details.  I’ve got a great committee to help me out, and I’ve also worked to ensure that we’re set up for success for vUE 2014.  We’ve already identified the vUE 2014 conference chair and technical chair, and they are responsible for everything.  I will act as a mentor to them as they go through everything, and I’ve tried to document what I think they’ll need to know, but I won’t be on the committee myself.  vUE needs to continue to grow and evolve, which means that it can’t have the same person running it.

I’ve got a lot to do in the next five weeks, but it’s going to be worth it.  vUE 2011 was a smashing success, and I’m hopeful that we exceed the high bar that we set for ourselves.

  1. It was originally supposed to be vUE 2012, but we had to move the dates to accommodate a few things. ↩
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.