Monthly Archives: March 2013

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.

user experience

starting over on your user experience

The HTC blog has a post from its Director of User Experience about how they redefined the HTC Sense, and did so via user research.  He doesn’t elaborate a lot on what research they did, but rather their key learnings and how that informed all of the design decisions that they made.

My little researcher heart goes pitter-patter when I hear of stories like this, of companies willing to step back and completely reconsider everything based on user research.  Go HTC!

user experience

User research != user feedback

2 Comments

This quote has been making the rounds again:

“User feedback is bad at telling you what to build. It’s great at telling you what you fucked up” – Phil Libin, CEO of @Evernote

I haven’t actually been able to find the quote in context, so I hope that Libin isn’t as ignorant about what user research brings to the table as he sounds in this Twitter-sized quote.

It appears to be making the mistake of assuming that gathering user feedback is the same as doing user research.  They’re different beasts.  It’s not difficult to show users something and get feedback on it.  User research is more than just showing something to people, writing down what they say or did, and then going back and telling people about that.

Feedback doesn’t just tell you “what you fucked up”.  If you think that’s all that you’re hearing in your user feedback, then you’re not listening to your feedback.  You’re only hearing part of the message in the feedback.  Don’t just take your feedback at face value.  Take the time to analyze it and understand it.  You’ll learn a lot about what you got right and what you got wrong.  If your users perceive that you got something wrong, then you’ve got to decide what to do about it.  I wrote a post about feedback and constructive criticism awhile ago that covers a lot of this.

Feedback also can tell you what to build.  By hearing what works and what doesn’t work from your users, you have the seeds of inspiration for building the next big thing.  It might or might not be related to what the feedback was actually about, but that’s the beauty of the human experience: every interaction we have impacts us, and it all comes together sometimes in ways that we can’t explain when we have that sudden insight that tells us what to build next.

But feedback isn’t everything.  Feedback is just a teensy subset of user research, and I sincerely hope that anyone who is CEO of a company knows that.  User research can tell you what to build.  The research that you do when you need to figure out what to build isn’t as neat or easy-to-conduct as the formative research that you need to do when you’re trying to figure out what to build, but it can lead to that lightbulb moment where you figure out what’s next.  If you don’t know what this entails, go find an awesome user researcher (hi) and ask.

iPhone

the iPhone and 4000 lattes

I was at Macworld when Steve Jobs announced the iPhone.  Several of us from my then-team were in attendance, and we all sat together in the main hall for the Stevenote.  And yes, I laughed when Steve called a local Starbucks and ordered 4000 lattes.

The fine folks at Fast Company have done some deep investigative journalism and went to visit that selfsame Starbucks.  Yes, really: Because Of Steve Jobs’s First Public iPhone Call, Starbucks Still Gets Orders For 4,000 Lattes.  Thanks to Fast Company, I now know that the Starbucks employee who answered the phone when Steve called still works there, and that people years later are still calling and asking for 4000 lattes.

Funny enough, now orders for 4,000 lattes are more common, thanks to the endless droves of Apple fanboys still wanting to partake in some aspect of Jobs’s legacy. “Before him, no [we never received such an order],” Hannah says. “After he made the call, everyone copied him, prank calling our store and ordering thousands of lattes–to this day!”

Apple, Mac

ten more reasons I hate iTunes 11

2 Comments

I’ve already given you ten reasons that I hate iTunes 11, but now that I’ve been using it for awhile, I’ve got ten more.

  1. The Artists view doesn’t show all of the artists that are in my library.  I have an artist where I have several hundred songs, and yet they’re not in the artist view.  All of the songs are tagged appropriately, and they live in the same folder as all of the rest of my music, but somehow this artist isn’t worthy of the Artists view.  
  2. Navigational behavior is inconsistent between views.  Here are some examples:
    1. If you open up the information for a song in the Artists view, you don’t get Previous and Next buttons (and their attendant keyboard shortcuts).  If you open up that same song in the Songs view, you do.  Both of these are lists of songs, why do I get buttons in one place and not in another?
    2. If you delete a song (which I’m doing a lot of, because the move to iTunes 11 has duplicated a bunch of songs) in the Artists view, you lose focus and have to click with your mouse again to get focus somewhere.  In the Songs view, if you delete a song, focus moves to the next song.  Why is this inconsistent?
  3. I keep on accidentally hitting the menu arrow next to songs, because it seems that its click target is a lot bigger than the button is, and it’s not in a consistent location.  For example, if I’m trying to shift-click to select several songs, I often accidentally hit that stupid menu arrow for one of the songs.  It interrupts my workflow.
  4. There is bloody well nothing on that menu arrow that I use, so it’s especially obnoxious that I keep on hitting it when I don’t care about it.
  5. I really miss iTunes DJ.  I used it all the time to just randomly shuffle through my complete library.  It let me rearrange the songs that were coming up, and I could remove things that I wasn’t in the mood for.  “Up Next” is not nearly as useful, especially since I can only see a scant handful of songs that it’s going to play next.  iTunes DJ is also the only place in iTunes where I actually liked Cover Flow.  (I mostly don’t mind the loss of Cover Flow, but I do here.)
  6. File > Display Duplicates is gone.  When you’ve got a library as large as mine, this feature made it a lot easier to identify duplicates, determine which one you wanted to keep, and delete the rest.
  7. Gapless albums are gone.  This was awesome for live albums, as well as albums where the tracks flow seamlessly from one to another (the canonical example here is probably Dark Side of the Moon).  This function keeps iTunes from cross-fading songs on gapless albums.  Now listening to live albums is annoying, and Dark Side is all but unlistenable.
  8. Search doesn’t always take you anywhere useful.  I like the drop-down that appears in search, but if you’re in the Artists view (which is the only view that I find even remotely palatable), searching just takes you to the artist where the album or song that you searched for is contained.  This is utterly useless if you have a lot of songs by an artist.
  9. It doesn’t remember where you last were if you change views.  Let’s say you had a song selected in the Artists view, and then you go to the Podcasts view.  Go back to Artists, and you’re back at the top of the Artists view.
  10. There are default settings for podcasts that I apparently can’t manipulate.  They’re not in the Preferences, they’re not anywhere on the odcasts page that I’ve noticed.  But every podcast has a little settings icon, and there’s a “use default settings” checkbox there.  I would like for the default to be that it downloads all available episodes, not just the most recent one.  I can’t do that, so I have to go to each and every podcast, click its settings, and change that value.  Why have default podcast settings if I can’t access them?

I’ve been using iTunes 11 a lot in the hopes that I could come to some kind of peace with it, but I still hate it every single time I touch it.

Nadyne, user experience

I’m speaking at DevFest on March 15

DevFest Silicon Valley is happening on March 15, and I’ll be speaking there.  My talk is titled “An Engineer’s Guide to Learning About Your Users”.  If you’re in Silicon Valley, you should join me.  In my 30-minute session, I’ll explain how to elicit information from your users (both directly and indirectly).  I’ll discuss the parallels between good code and good research, and explain how the development lifecycle applies to research too.