VMware has a new publication: the VMware Technical Journal. There’s some awesome content in there, especially the case study about how we set up the VMworld Hands-On Labs.
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.
sooper sekrit message to Project Octopus private beta participants
This is sooper sekrit, so don’t tell anyone!
If you’re participating in the Project Octopus private beta, there’s a new iOS app available in the iTunes Store.
today’s game
Today’s game:
s/cloud/clown/g
Go to your favorite tech news source and have fun. Here’s a random sampling from Business Week:
- Could clown computing hurt outsourcers?
- The madness of the clowns
- Computing heads for the clowns
- Will the antivirus industry survive the clown?
I’m now going to have to spend this afternoon’s meeting about vCloud Director trying desperately not to giggle every time there’s ‘cloud’ on a slide.
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.
VMware View Client for Mac and Linux are now generally available
In December, we released a tech preview of our View Client for Mac and View Client for Linux. They’re now generally available with updates and fixes. While we were in there updating the code, there’s also updates to the View Client for iPad and View Client for Android. You should go forth and download.
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.
how much engineering effort is lost to DST every year?
I haven’t yet met anyone who really likes Daylight Savings Time (DST). Every spring, everyone complains about losing an hour of sleep. Then you walk through your home and get annoyed by the clocks that aren’t updated automatically. You get even more annoyed when you have a clock that should’ve been updated automatically but wasn’t, or it somehow got updated incorrectly.
Anyone who has colleagues, family, or friends overseas knows that DST is more complicated than that. Other countries might or might not participate in DST, and the dates on which they change their time are not the same.1 When you’re trying to book a meeting or make a telephone call, there’s a few weeks every spring and autumn where you double-check to make sure that you’re not doing it at the wrong time.
DST is a massively complex beast. In the US, it wasn’t until 2007 that the dates for the time change were standardized across the country2. Before that, states and localities could opt out of DST, although you should note that Arizona and Hawaii still don’t observe it.3
“That doesn’t sound too bad,” you’re thinking to yourself right now. There’s not a lot of error conditions to be had here. You could get the date itself wrong, but it’s now standard enough that this isn’t too likely. You could get the time zone wrong, which is probably most likely to be a concern if you’re close to a time zone boundary or if you’re in one of the places that doesn’t observe it. Both of these are probably not going to require a lot of engineering effort.
And it’s not, so long as you’re only dealing with the US. But now pause and consider: as of this writing, there are 196 countries in the world4. Each of these countries potentially has their own dates for recognizing DST. For the countries which observe DST, the dates on which they do so might or might not be standardized, or might be standardized but get moved around if a local government decides to make a small tweak that year. Localities within these countries also can choose not to observe it. Don’t forget that the northern hemisphere is observing DST in one direction, and the southern hemisphere is observing it in the other direction. While you’re at it, realize that “Pacific time” isn’t just the name of a time zone in the US. Wikipedia has a huge page about daylight saving time by country, which gives you an idea of the complexity of this issue.5
All of this is complex enough when we’re thinking about a single clock that needs to update. Let’s add in another layer of complexity: client/server. Your computer has its own internal clock, and it updates against a time server somewhere. That cell phone in your pocket has at least two time sources. It’s got its own internal clock, and it’s also getting the time from the nearest cell towers. Your mail application gets its time from the local computer, and it’s also communicating with the mail server and getting items there that are timestamped. The examples here are all but endless.
In software engineering, we talk about “edge cases”. An edge case is a problem that occurs when you’re at the outside the usual operating parameters. DST is a rat’s nest of edge cases. You can come up with a dozen of them without even trying hard. Anyone who’s worked on an application that deals with this has a horror story about the year Venezuela changed their dates for DST at the last minute, or somehow one server didn’t get the latest code, or a million other edge cases.
I have to wonder: how much engineering time gets wasted on DST every year? Just think of all of the tech companies that have to deal with this: any company that makes a mail or calendar application (IBM, Microsoft, Apple, VMware, …), every mobile phone provider (AT&T, Verizon, T-Mobile, …). Maybe the tech industry could come together to abolish DST and succeed where so many others have failed.
- In 2001, when I moved from Sydney to Silicon Valley, I was in Sydney for their “fall behind” time change, got on an airplane, and was then in the Valley for our “spring ahead” change. Between that and jet lag, I was in my own personal time zone for at least a couple of days. Nadyne Standard Time? ↩
- Second Sunday in March, first Sunday in November, in case you’re interested. ↩
- To confuse matters further, the Navajo Nation in Arizona does observe DST. ↩
- The UN recognizes 193, but that doesn’t include the Vatican, Kosovo, or Taiwan. ↩
- According to that page, Russia has now stopped observing DST, which I have to believe caused some software engineers a couple of sleepless nights in coding that update. ↩