Category Archives: Nadyne

unintended consequences

In software engineering, things that you think are a joke sometimes take on a life of their own.  To wit: the humble origins of the blink tag.  A bunch of Netscape engineers got together for beers in Mountain View one night, where one lamented that none of the HTML extensions would work with Lynx.

There were two unintended consequences to this beer-fueled conversation:

  1. The blink tag was coded up that very night
  2. The engineer who made the lamentation met the woman who ultimately became his wife.

You never know what will come out of happy hour conversations.  They often have unintended consequences.

oh, Sony, how can you get it so wrong?

A few months ago, I was deeply in love with PopMarket.  It’s a daily deal website for music, and I went through an intense phase of buying lots of music from them.  But then it became clear how bad this relationship was for me, in the form of a botched order.  Last September, I ordered a three-album set, one of which was a double-disc version of Janis Joplin’s seminal Pearl.  When I got the order, I discovered a manufacturing error: instead of Pearl, the discs inside the packaging were of Earth, Wind, & Fire.

I wrote to PopMarket, got an almost instantaneous response where they sent me a replacement, and thus entered the rabbit hole.  The replacement had the same error, and then the replacement for the replacement had the same error.  After a few weeks of trying to get them to either send me correct discs or refund the order, I gave up.  And I haven’t ordered from PopMarket again.

Last week, I got an email saying that my order of Johnny Cash’s The Legend had shipped.   This is one of the albums that I had ordered, back in those heady days, but I received it months ago.  I thought that their system must have hiccuped and sent a confirmation mail out again, so ignored it, but then the album showed up on my doorstep.  So I wrote to them again, asking (a) what to do with this album that they’ve entirely inexplicably sent me, and (b) whether they have any intent at all of sending the order that they still haven’t completed.  The response is rather opaque:

I’m sorry for any inconvenience that may have caused. I’ve forwarded your message to our warehouse department for review. As soon as I receive any further information I will let you know via email.

Err, yeah.  You’ll excuse me if I don’t hold my breath on that one.

I still get the daily PopMarket emails, and sometimes I want to click through to order, but I always hold myself back.  I’ve learned my lesson.

Weebly has an obvious security flaw

A long long time ago, back when Gmail was still in invite-only beta and invites were actually difficult to come by, I snagged nadyne@gmail for myself.  This has provided years of unintentional entertainment.  I’ve amassed quite the collection of other Nadynes who forget their email address or make a typo when entering it.

Today, via a new Nadyne, I learned about a website called Weebly.  If you’re not familiar with it (I wasn’t before this), it’s a website and blog creator.  Since that other Nadyne got her email address wrong when she created her website, I got the confirmation email.  The confirmation email included a link called “auto-login to Weebly”.  I clicked it, and found myself logged in to Weebly.

Yes, that’s right: without entering a username or password, I was able to login to someone else’s Weebly account.  What fantastically bad security.  I can’t possibly be the only person who has received such an email erroneously.  Weebly should require the user to enter their password when they’re logging in from a browser that they’ve never used before, even when clicking on the link from their confirmation email.  This is such a basic security mistake that I couldn’t trust them with getting their security right elsewhere.

I can do anything that I like with her website.  Since I don’t actually know this other Nadyne’s email address, I posted something to her new site saying that I’ve changed her password and that she needs to update her account information with a new password and with her accurate email address.

This collection of other Nadynes has given me a long list of websites that I won’t do business with as a result of their bad security.  One particular website actually emailed me, in plaintext, another Nadyne’s complete information: her real name, address, phone number, SSN (yes, really!), and credit card number.  Usually I just email the Nadyne in question to let her know that she needs to (a) update her account to reflect her real email address, and (b) be careful about doing business with a company that will send out so much personally-identifying information via email.  Perhaps it’s time to mine this for a new series of blog posts.

Q&A: why should I work for VMware?

During interviews, I often get asked by candidates why they should work for VMware.  There are lots of reasons to do so, but here’s one of my favorite ones: VMware CEO Paul Maritz was just ranked in the top ten CEOs by Glassdoor.com.  Their ranking is based on employee reviews.  Having trust in your CEO is a great thing, and is definitely a great reason to work here.

The user experience team at VMware is still growing.  Here’s a job description for a senior interaction designer; we’ve got other positions in interaction design and research, for both new college hires and experienced hires.  Ping me if you’d like to learn more or would like to apply.

Q&A: what applications should I know for a career in user experience?

This week, I got asked a couple of questions about applications for user experience people.  One was from a researcher asking which applications they should know how to use, another was from a designer worried that they don’t know how to use Flash.

Three minutes on the internet will reveal plenty of UX people who have very strong opinions about the applications that you should know.  Sometimes they’re advancing the idea that you don’t need to use a heavy-duty application, but rather that a (relatively) lightweight application can do the job.  For an example of that, check out the power of Keynote by Paul Woods.  Sometimes they’re putting a stake in the ground and advancing that there is only one true way, such as this reference to someone who won’t hire designers who can’t code.

I generally don’t care about specific applications.  Job ads often list a  bunch of applications, and I know that I’ve written job ads myself with a list of apps, but I don’t think that anyone needs to know every single app on that list.  A candidate should probably know at least a couple (and I’ll get to why in a minute), but knowing the whole list isn’t necessary (or even necessarily useful).

What matters for user experience is communicating with your team. Using the right application is a method of communication.  If you’re working closely with a development team that tracks everything in Bugzilla, you need to use Bugzilla too.  If you’re working with a design team that loves OmniGraffle, you should learn how to use OmniGraffle.  If you’re working with a PM who never seems to have any application other than PowerPoint open, you’d better make sure that everything you send to them is a .ppt file.  If you don’t use their application of choice, then you’re decreasing the chances that they’ll open your file or pay attention to your work.  You’re negatively impacting your communication.

For researchers, I rarely care about specific applications.  They’re nice-to-have, but they’re not need-to-have.  Email, a word processor, and a presentation app are absolute requirements.

For designers, I think that you should be a wizard in at least one design application, and you should be proficient in another couple.  Knowing more than just one application shows me that you’re flexible and adaptable.  I especially like it when you can tell me that one application is great in this case, but another application is great in this case.  And I want to know how you’ll get up-to-speed doing designs in a new application too, since it’s all but guaranteed that you’re going to have to learn a new one.

For researchers, I don’t think that you need to be a wizard in a design application, but you should have at least a reasonable knowledge of a couple.  You’re going to be communicating with designers, so just as you need to be able to communicate with that PowerPoint-lovin’ PM, you’re also going to have to be able to communicate with your team who loves OmniGraffle.  When you get a mockup from a designer that doesn’t quite work for your usability study that starts in 10 minutes, you can tweak it yourself.  It makes your life as a researcher that much better to be able to use the design app(s) that your team prefers.

Leaving aside the basics of email, word processing, and presenting, I don’t think that there is any application that I think that every single UX person should know.  The application is the tool.  I care about what the outcome of using that tool is, but — so long as you’re willing to use other tools when necessary or appropriate — I don’t care what tools you use to do the job.

casual sexism in software engineering

Casual sexism happens all the time in software engineering.  If I hear one more person say that they want to make their app easy enough for their mother or grandmother to use, I’m going to scream.  Let’s stop assuming that women aren’t technical or aren’t willing to understand something.  And for the love of all that is good in this world, don’t try to justify this one to me.  I don’t care if your mom isn’t actually technical, you can still come up with other examples of people who aren’t technical.  Don’t be lazy

Women in software engineering have to deal with this casual sexism every day, and mostly we let it go.  When you hear it so often, it’s hard to identify it for what it is, and you get tired of being told that it wasn’t actually intended to be sexism.  But then you get hit between the eyes with yet another example of casual sexism, such as this displayed in Sqoot’s invitation to an “API jam” in Boston:

That’s right, ladies, you’re just a perk at a hackathon, like the massages and booze.

At first, they tried the “it was just a joke” defense.  It took more outcry for them to issue an apology, first by saying that they were “really sorry” (a Google Doc that now no longer exists), and then by saying that “we can do better“.

Yes, you can do better.  You can realize that women aren’t a perk.  You can realize that you can’t blow it off as “just a little humor”.  You can realize that your first non-apology apology isn’t acceptable, and that your second attempt saying that you were just trying to “call attention to the male-dominated tech world” can’t possibly be accurate.  Beer wenches call attention to beer and breasts, they’re not an attempt to address gender inequality.  Would you try to make call attention to the lack of diversity by pointing out that you’ve got Latinos cleaning the bathrooms?

There’s only one acceptable apology here: “I’m sorry.  I was wrong.”  No explanations, no posturing, just an admission that you got it wrong.  After that admission, the next step is to figure out how you got it so wrong and what you’re going to do about it.  Maybe, for example, you need to reach out to local women’s developer groups to try to do something about the “male-dominated” nature of hackathons.  Do something, don’t just say that “we can do better”.  Tell us what that better thing is that you’re going to do, and make sure that it actually is something better.  If your solution is just making sure that there are hot boys to bring pink frilly drinks, you’re still missing the point.

research contractor needed

My team has a very large research project coming up, and we’re looking for a contractor to come in and help us for at least three months.  In this research project, we’ll be doing a lot of studies in the usability lab.

For this position, we need someone who will own the complete research project.  Working with my team, they’ll define the scope of the project and how we will go about answering the questions that we have.  They will create the research plan and all usability test materials, including (but certainly not limited to) creating a screener to find participants for the study, setting up the environment for testing, and creating the task list and script.  They will conduct the research and analyze the results (which we anticipate will be a mix of qualitative and quantitative).

Candidates should have at least an undergraduate degree in HCI or a related field and 2-3 years of experience in conducting UX research.  A stellar candidate will have experience in conducting research on highly-technical enterprise software.

Interested?  Have questions?  Email me.

communication is how I get stuff done

Earlier today, I read an interview with Karina van Schaardenburg, a user experience researcher at Twitter, in which she discusses what she uses to get her job done.  In essence, she’s got a laptop for her own use, and she’s got some tools that she uses for data collection and analysis, and she’s got some hardware and software that she uses when she’s conducting her research.  As I read it, it was all familiar to me.  Specifics aside, Karina’s setup is pretty similar to my own.  But I felt like something was missing.

The interview focuses on applications and hardware, and all of the interviews on the usesthis.com site focus on that.  Which is fine, in term of the mechanics of what I do as a researcher.  But the question that the site is trying to answer is “What do people use to get stuff done?”  The tools that I use aren’t what I do to get stuff done.

As a researcher, what I actually do to get stuff done is communicate.  I communicate with the design team, the program management team, the development team, and anyone else who I can get to talk tome.  That communication is about deciding our goals and priorities.  Then I communicate with our users to learn about what they do.  Sometimes that communication is conducted via survey, sometimes by interview, sometimes by contextual inquiry, sometimes by usability study.  After I’ve completed my research and conducted my analysis of the data, I then circle back with everyone at my company and communicate with them again: what I learned, what steps we should take next.  I keep up this communication to ensure that actions are taken, based on my recommendations.

In my opinion, the tools themselves don’t matter that much.  Yes, I’m a Mac user, and I use Morae to record my studies, and I use SlideRocket to give presentations to my team, and I use Apple Mail to communicate with everyone involved throughout the process.  But those tools isn’t what makes me a good user experience researcher.  If you took my Mac and my SlideRocket account away from me, I would still produce good research.  The tools are all but orthogonal to the discussion of how I get stuff done.  The thing that I actually use to get stuff done is communication.

This isn’t a complaint about the idea behind usesthis.com, and it’s certainly not a commentary on Karina.  I think that we understand intrinsically that copying someone else’s setup won’t magically imbue you with their traits and talents.  It’s pretty clear that using BBEdit and jailbreaking my iPhone won’t make me a novelist like Charlie Strouss.  The tool is only the tool.  Answering “what tools do you use to get stuff done” is very different from answering “what do you use to get stuff done”.  Communication is what I use to get stuff done.  Everything else is just a tool that supports that communication.

how to prepare for a UX on-campus interview with VMware

Today, the VMware Careers blog has a great post about how to prepare for a technical on-campus interview with VMware.  It’s a great post about technical interviews, and reminded me that I should post about how interviews for our user experience team differ from those interviews.

What types of questions do we ask?

We want to learn about your user experience skills.  We’ll ask about projects that you’ve done, and ask about the design and research process that you went through during that project.  If you’re doing a design interview, you can expect to do some sketching as we ask you to solve a design problem.  If you’re doing a research interview, you can expect to devise a quick research plan to answer a question.

Practice your UX skills

You can expect to flex your design and research skills during our interview.  As you’re working through your design or your research approach, make sure to explain your thought process, and ask questions if you need clarification.  Be comfortable in front of a white board as you sketch your designs.

Your resume is not a standalone document

Your resume doesn’t stand by itself.  Tell us about what isn’t captured on your resume.  If you’ve got portfolio pieces that are related to items on your resume, be prepared to show them and explain them.

Don’t be afraid to tell us about what worked and what didn’t work.  For example, if you had a research project where no changes were made based on your results, talk about what happened, why it happened, and how you might approach it differently to get a better outcome.  If your design didn’t work, tell us what didn’t work about it and what you learned from it.

Ask questions

We want to know that you’re going to fit into our team, and we want you to be happy here.  Ask us questions.  Is work/life balance important to you?  Do you want to attend conferences and publish papers?  In what areas do you want to grow in your career?  Is working for a green company important to you?  In other words, think about what you want in your first job out of college, and ask questions to make sure that you’re going to get that with us.

An interview is not, and should not be, a one-way street.  It’s not just about the employer determining if you would be a good employee.  It is just as important for you to decide if this is the right company and right team for you.  If you’re not happy, your job performance will suffer, and ultimately your career will suffer.  Take advantage of the time that you have with us to gather information that will help you decide whether this is the right fit for you.

Speaking of questions: if you’ve got ’em, ask away in the comments, or email me.