Category Archives: Nadyne

Q&A, user experience

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.

Microsoft, user experience

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. ↩
user experience

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.

user experience

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, user experience

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.

user experience

the power of “thank you”

User researchers are always asking for favors of people.  It’s the nature of research.  You’re asking your design team to help you get prepared for the research, often creating or helping to create the materials that you’ll use in your research.  You’re asking your participants to give up some of their time to be poked and prodded by you1.  You’re asking your application team to make changes to their plans based on what you’ve learned in your research.  It can make a user researcher feel like they’re always taking and never giving.  It’s not true, of course: your work gives your designers and application team better insight, which results in a better product for your users.

I know that I’m asking a lot from many other people as I do my work.  As I’m doing so, I remember to thank them for their work.  I thank my participants for taking the time to talk with me.  I thank the design team for working with me and ensuring that we had the right design artifacts to share with study participants.  I thank the application team for helping me understand what they need to know, what they have time to implement, and how my work fits into their development cycle.  I thank everyone for being involved with the work, for sharing their thoughts and ideas, for listening to what we learned and asking questions to clarify points, and for sharing their thoughts and ideas for how we move forward.

Remembering these simple courtesies helps smooth the way for a user researcher.

  1. Figuratively, not literally. ↩
user experience

the scaling of user experiences

A colleague pointed me at an article by Jonathan Courtney titled “Want the Best User Experience? Make it Harder to Add Features”.  I thought I would read an article that preached to my choir.

I have long advocated delivering fewer and better features over delivering a laundry list of features.  How does a feature fit into the overall user experience?  If we cut part of it, do we negatively impact the user experience?  It is much better to deliver fewer features that create a great user experience, rather than delivering a laundry list of features that don’t quite fit together to meet the user’s needs and goals.

Except the article isn’t actually about being harder to add features.  There is only one sentence that I think comes close to the title of the article, which is this one: “It means that adding features down the line will need to be a careful process of consideration rather than just something that’s tacked on.”  This is dead-on: we shouldn’t just add features to add features.  We should carefully consider how a new feature fits into our existing application and how we can make it fit into our users’ workflow as seamlessly as possible.

Then the author takes us down a completely different path:

We’re at a time when apps and software are becoming more and more focused. Successful companies that previously took the kitchen sink approach have done a u-turn and are now decoupling features to create entirely separate experiences. Foursquare has separated its “checking in” function to Swarm. Facebook created Messages (and many other apps), Path recently released Talk.

Now I see that the article really isn’t about user experience and the number of features in an application.  It is only talking about mobile development, and specifically about social media on mobile.  Even worse, it skips over user reaction to these decisions in mobile social media apps.  A quick glance at the iTunes Store reveals how popular this method is with users. In separating Foursquare into two applications, Foursquare went from having a 4-star rating to a 2.5 star rating, and the new Swarm app has a 1.5 star rating. The current version of Facebook Messenger1 also has a 1.5 star rating. Only Path has retained its 4-star rating, although it’s interesting to note how many of its reviews specifically say that they didn’t use the private message feature before the split (that is, the feature that is now the basis for Talk).

By focusing an application on a single use-case, we run the risk of not thinking about the user’s overall goals and workflow. How do all of these individual use-cases come together to create a workflow? Can users seamlessly continue their workflow, regardless of what application it’s in? Does the concept of single-use application work for desktop or web applications that aren’t social media?  The author provides no evidence.

We should not deliver a laundry list of features, but rather deliver a fantastic experience on a subset of those features. Let’s not deliver 80% of a feature so that we have enough time to get another feature on the laundry list. Let’s deliver 100% of a feature2 that truly meets our users’ needs and helps them accomplish their goals easier and with less cognitive load.

  1. that is, the version where Facebook forced users to use Messenger to send messages; in previous versions of the Facebook and Messenger apps, usage of Messenger was optional. ↩
  2. Okay, maybe 95%. ↩
Apple, women

“Integrating women into the Apple community”

Brianna Wu, head of development at Giant Spacekat (who have just released their first iOS game, Revolution 60) wrote a great piece titled “Eve wasn’t invited: Integrating women into the Apple community” for Macworld.  The conclusion is fantastic:

When I was a teenager in the 90s, I had few female role models to look up to in computer science; it’s simply not acceptable for this to still be the case in 2014. Next year at WWDC, I want to see at least one woman in a public speaking role during the WWDC keynote. There are many bright, smart, well-spoken female Apple engineers; let’s put them on stage and be role models for their peers and our daughters. Or Apple’s Angela Ahrendts, who may not be a developer, but her business savvy and presentation skills seem like they would be well-utilized at next year’s keynote. And I want to see more women and minorities at WWDC next year. We’re a small crowd, but we do exist, and having more of us at the conference will emphasize this.

Go check out the whole article!