Grace Hopper sessions I’m looking forward to

Oh, the places you’ll go!

Wednesday:

  • 9:30am: opening keynote by Shafi Goldwasser
  • 12:30pm: “Executive Presence: Making the Leap” workshop
  • 2pm: “Leadership Strategies for High-Impact Women” workshop
  • 7:30pm: poster session (come by and say hi!)

Thursday:

  • 8:30am: keynote by Satya Nadella
  • 10:15am: “Accountability and Metrics for Gender Diversity” panel
  • noon: “Humans, Devices, and How They Live Together”
  • 2:15pm: “What Do You Mean It Isn’t a Meritocracy?” birds-of-a-feather

Friday:

  • 8:30am: keynote by Arati Prabhakar
  • 10:15am: “Designing Secure and Privacy-Aware IoT and Wearable Technologies for Healthcare”
  • noon: “Systers Creating Change Everywhere Through Community and Technology Initiatives”
  • 1pm: Systers lunch
  • 3:30pm: “Trends and New Directions in Software Architecture”

I know I’ll go to more sessions than this, these are the ones that I really want to see.  What are yours?

Silicon Valley diversity irony from The New York Times

This weekend, The New York Times published an op-ed about “Silicon Valley’s Diversity Problem”.  A dressing down from the Times on diversity is painfully ironic, given that the Times has the biggest gender gap of the US’s ten most widely circulated newspapers.  In the Times, 69% of its bylines are men.  That’s not all that different from Google’s workforce, which is 70% male.

The Times has suggestions for improving Silicon Valley’s diversity problem, including this one:

Not all tech industry employees are engineers and programmers. The companies employ large numbers of people who manage projects, market services and design products. Many of these jobs do not require a computer science or an engineering degree. But the proportion of women and minorities in these types of jobs is not much better than the proportion in technical positions. Companies should make efforts to hire a more diverse group of workers — including more liberal arts graduates — for nontechnical jobs, according to Vivek Wadhwa, who has written a book about women in the technology industry.1

The Times assumes that engineering and programming jobs require a computer science (CS) or engineering degree.  This isn’t true, and hasn’t ever been true.  Anecdotally, I know programmers without degrees at all.2  I know programmers with philosophy degrees, and English degrees, and history degrees.  There have been plenty of times where I’ve been in a roomful of developers where I was the only one with a CS degree.  Software development changes fast.  We value people who are self-taught.  A CS degree is not required for a programming job.

Better is that their solution is a two-tiered solution to engineering.  It’s the same as their two-tiered solution to journalism.  At the Times, as elsewhere in journalism, women are significantly more likely to write articles about lifestyle or health.  Articles about crime, justice, and politics are still more likely to be written by men, as are op-eds.  The hard news and analysis goes to men, the soft news goes to women.  And so too should the hard engineering problems go to men, while the soft stuff like project management or design go to women.

According to “The most comprehensive analysis ever of the gender of New York Times writers”, only five sections have articles that are mostly written by women: Fashion, Dining, Home, Travel, and Health.  According to The Status of Women in the U.S. Media 2014 (PDF), men have 3 times as many page 1 quotes in the Times than women do.  The Times would do well to improve its own record on diversity before advising others what to do about theirs.

We should not divide software development into men’s work (programming) and women’s work (“manag[ing] projects, market[ing] services and design[ing] products”, as per above).  Women are just as capable as men of programming.  Men are just as capable as women at project management, marketing3, and design.  Tech companies need real diversity, not enclaves of women in specific roles in a misguided attempt at diversity.

  1. I’m not even going to begin to get into the problems about quoting Wadhwa as an expert about women in technology.
  2. I rely on anecdote because I wasn’t able to find data about how many programmers actually have CS or relevant engineering degrees.  If you’ve got a source, please share.
  3. Come on, has no one seen Mad Men?

“Four Interactions That Could Have Gone Better”

I’ve been doing a fair amount of tech events lately, which is probably why this blog post from Bridget Kromhout resonates so strongly.  She starts off thusly:

If you’re wondering why women don’t attend the conferences, unconferences, meetups, or hackathons you enjoy, or why you don’t seem to make meaningful professional connections with the ones who are there, maybe they’ve been having these conversations often enough that they’re tired of it, and would rather spend their time doing anything else at all.

This is part of my decision-making process for tech events.  How likely is it that I’m going to have to deal with this type of interaction? Given other tech events that I’ve attended lately and how often (or not) I’ve had to deal with this type of interaction, do I have sufficient energy for dealing with this type of interaction if it does occur this time?

Nadyne @ Grace Hopper

Next week is the Grace Hopper Celebration!  I’m excited.  It really hit me last night as I was putting the final tweaks on my poster.

Here’s my current schedule for the event:

Want to meet up for coffee, lunch, dinner, drinks, something?  Ping me.

(Edited 10/2 10:32am to add a link to GHC and to add the ABI communities meetup to my schedule.)

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.

BP and college students have something in common

When I was working at Microsoft, I had the opportunity to observe research that one of my colleagues conducted about how college students used Word.  During a focus group, while discussing writing papers, the students discussed methods that they used to get around a page-length requirement.  I’d heard of most of them: changing the font, changing the margins, changing the line spacing.1

I was amused to read that BP’s lawyers have resorted to the same methods.  This is quote from the judge’s ruling:

BP’s counsel filed a brief that, at first blush, appeared just within the 35-page limit. A closer study reveals that BP’s counsel abused the page limit by reducing the line spacing to slightly less than double-spaced. As a result, BP exceeded the (already enlarged) page limit by roughly six pages.

The Court should not have to waste its time policing such simple rules — particularly in a case as massive and complex as this. … Counsel’s tactic would not be appropriate for a college term paper. It certainly is not appropriate here.

It occurs to me that I hope that I haven’t given anyone any new ideas about how to get around page limits by writing this.

  1.  I recall one that was new to me: changing the font (or font size) of just the periods: professors who checked for correct fonts and font sizes usually wouldn’t bother checking to ensure that the correct font was used on every single character in the document, and the difference of a point or two of font size on a period wasn’t visually noticeable.  If you were close to, but not quite at, the minimum required page limit, increasing your period size could be enough to get you over the line.

inspiration

I noticed that the official VMware tweets about their Q&A with me talk about “the inspiration behind my work”.  They got my inspiration to get started in computing, which isn’t the same as what inspires my day-to-day work.

I like solving hard problems.  The hardest problems aren’t necessarily in the code.  They’re the ones that keep people from getting to that code, or that keep that code from being something that people want to put to use.

My inspiration is seeing someone get frustrated because they can’t do something.  My inspiration is seeing someone spend hours searching online for help.  My inspiration is seeing someone trip over something, not even notice it because they always trip over it, and continuing on with that little bit of lingering annoyance that they can’t identify because they didn’t notice it when it happened.

My inspiration lies in coming up with ways that make people’s lives better.  It might be a little thing, like fixing that thing that trips them up every day but that they don’t notice.  It might be something bigger, like giving them the tools to do something that they never knew was possible but can make their days go so much smoother.  It might be in providing great APIs so that they can roll their own solution that perfectly meets their needs, and in them having the satisfaction of a job well done as they roll their own solution.

My work is invisible.  When it’s done well, you’ll never see it.  My inspiration is in keeping your life ticking along, making things easier for you, without you ever even knowing about it.

what’s next?

I recently conducted research which revealed that we had failed to consider one of the most important questions for our users: what’s next?  During the research, users successfully got through each individual step.  When it was time to transition to the next step, they couldn’t figure out what to do.  They knew what their end goal was, they couldn’t figure out how to get there.  One of my recommendations to the team is to consider how we will guide the user through the whole process so that people can accomplish what they set out to do.

When we develop applications, we break workflows up into features, and we often break up features into smaller pieces.  This process helps us build software.  It’s very easy for this process to make its way into the interaction design process: we design part of a workflow, and forget to design the glue between the individual parts of the workflow that turns it from a string of features into a workflow that helps users accomplish their goal.

Laura Klein looked at this problem from the other direction: coming up with an idea to improve your product, and then watching it get bigger and bigger as you consider what happens next.  Nothing exists in a vacuum.  There is always something that happens next.  A successful product considers what happens next, and sets its users up for success in getting to that next step and accomplishing what they really want to accomplish.

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.

a Macintosh girl in a Microsoft world

© 2010-2024 go ahead, mac my day All Rights Reserved