Monday, April 28, 2014

Blog Blog Blog

I haven't posted here for a while, but that doesn't mean I haven't been writing!  Here are a couple of blog posts I've written (and co-written) for the Yammer Product Blog:

My colleague Neil and I write about how we did user testing during the dogfooding process for a feature that got a lot of attention from the higher ups. 

From the post: 
"It can be scary to hear upper management strongly disagreeing with your product decisions. Take the feedback into consideration, take a deep breath, make a hypothesis, and test it. Don’t waste time trying to design a solution to each problem you hear about as you hear about it—you’ll quickly drown in unsolved problems."

In this post, I take a page from Social Psychology. I talk about brainstorming what the inhibiting and promoting pressures are of people using a product, focusing more on what is keeping people from doing the action you want them to do.

From the post:
"In product, we often focus on promoting instead of inhibiting. We phrase problems around actions we want the user to do (or do more of), and build features around that. Matt Wallaert encouraged us to instead focus on the inhibiting factors that are blocking our users. What are the real barriers keeping people from using our product?"

Sunday, June 16, 2013

Lean UX NYC and Tomer Sharon's "Noticeability Test"

It's been a while since I last posted...way too long. I'll just go ahead and dive right in.

I went to the Lean UX NYC Conference a while back (in April). It was a great conference! It was 3 days and held at NYU - the first day was full of short 20 minute talks and the last two days were all workshops. A few talks and workshops were about UX Research.  My favorite talk was given by Tomer Sharon.  Tomer is a user experience researcher at Google in NYC and author of the book It's Our Research. The reason it was my favorite was because he actually talked about a research method I had never heard of before. Yay learning! 

Also, there was a guy at the conference - I'm blanking on his name - who was sketching up the takeaways of the talks as they were happening.  So here is a sort of infographic of Tomer's talk (and others).

And here's the rundown of his talk and the method:

Tomer opened his talk by saying "don't listen to users - observe their behavior." He emphasized watching what they do. He cited the psychology of attitude and behavior - there's a negative relationship between what people say they will do and what they actually do. Tomer said "never ask what is their feedback - they want to be nice to you - just WATCH them - don't show a design to them and ask what they think, give it to them and ask them to use it, and then watch what they do."

Tomer then went on to talk about the question of whether users notice stuff. He mentioned that eye trackers are not mind readers; they are only good at telling us where people look, not what they notice. We don't know the why when using an eye tracker. So he developed the noticeability test. Here's how it works:
  • The noticeability test is a research technique for noting whether people notice key elements in design. Users are asked to recreate a screen based on their memory.
  • You will need to:
    • Print out a screen
    • Cut it into elements
    • Print and cut out non-elements (things that weren't there)
    • Mix them up
    • Have blank paper, sharpie, and tape
  • Hand the kit to the user after they complete a task. Explain that these are elements of a screen and ask them to re-assemble it. Add things that weren't there and take things that were there out. You can say "something must have fallen and got lost - here's a pencil, can you sketch it?" Then observe:
    • Did they put key elements in place? 
    • Did they leave out what doesn't being? 
    • Did they draw elements that weren't there?
  • Gives you crystal clear answers to the question "did they notice it?" 
  • Watch them behave rather than asking what they noticed.
I love the idea of trying out this method.  I have tried to ask users if they had noticed certain elements of a page before and the way I did it was just to ask them about it before having them go to the site.  These were users already familiar with the site.  But, this method seems way more effective.  And of course, as to be expected, I love the arts and crafts aspects of this method!  I found Tomer's slide deck about the noticeability test (from a different talk) here.

Also at Lean UX NYC, I went to Tomer's workshop about getting buy in from stakeholders, which was also great.  I think most of that is covered in his book, It's Our Research.  If you haven't read it yet, do it!  

Wednesday, October 17, 2012

Interviewing for UX Research Positions

After contracting part-time for Shoefitr for 5 months (or so), I decided it was time to get back on the horse and try applying to jobs again.  This time, revisiting my cover letter and résuméI could see exactly where to trim the fat and concisely explain my relevant experience.  I now know the language - I can comfortably talk about testing a low fidelity vs. high fidelity prototype, speak with confidence on doing research with a big budget vs. no budget, and I have an artillery of tools I can reference.

I applied to several jobs around the end of August/beginning of September.  About two to three weeks later, I was speaking with four companies at once and setting up interviews.  I was referred to two of the companies.  For one, I saw on LinkedIn that my friend knew several people at this company, so I reached out to him, he made an introduction, and my résumé got forwarded without ever applying formally.  I had never done this route before, but it worked out pretty well!  The companies I applied to were a consultancy, a pre-IPO startup, a recently acquired startup, and a larger company.  In hopes that this will help someone who might be applying to jobs now, I'll go ahead and talk about the general interview processes, but I won't name any names.

Almost all of the interviews followed this general format:

1) Recruiter reaches out in an e-mail and schedules a 30 minute "screener call"
  • These calls typically involved me explaining my research background and I talked about why I was interested in the company.  It's definitely good to ask questions during this phase.  Not all of these "screener calls" were with the recruiter.  A couple were with members of the team I was interviewing to be hired on to.  
  • A note on recruiters - some are knowledgeable about the position they are hiring for, and some are not.  It can at times seem like they are speaking another language and you are not talking about the same job.  Don't be discouraged - press on and talk about how your experience is applicable.  You will at some point talk to someone more knowledgeable about the job. 

2) Two hour on-site interview 
  • For most of these, I spoke with groups of 2 or 3 for four 30-minute sessions.  For some companies, I had one-on-one 30-minute interviews with individuals.  

3) Final round on-site interview
  • I came back to interview with more people whom I hadn't met yet.  These were usually all pretty similar to the first on-site.  Most of them were about two hours.
  • One of the companies, the consultancy, had me come in for an all-day final round interview.  I did a mock usability test, analyzed my results, created a PPT presentation, and presented to a group of people.  This one was exhausting!  I was also taken out to lunch and had a meet and greet with almost everyone in the company.

That was the general process and schedule.  Below, I'm going to talk about other things that happened during interviews and give some advice and tips.

Debriefing with Recruiter/HR Person
  • For most of these interviews, the last person I met with would be the recruiter or the HR director.  This is the time when they would ask me how I was feeling about the company, if I had any concerns, and they asked me what my salary requirement was.  
  • For the final round interviews, when I met with the recruiters, I mentioned that I was interviewing with several companies.  This put a fire under them to get back to me quickly!  

Interview the Company
  • Don't forget that you are interviewing the company as well.  Some of the companies were highly organized and gave me a detailed schedule of who I would be meeting with and when.  
  • Many made sure that I was "checked on" and that my interviews were not running long.  You could tell that my time was valued and respected.
  • For one of the companies, however, despite getting a detailed schedule, I was left in a conference room for 40 minutes and not checked on.  I had to go to the front desk (on another floor) to ask the receptionist what was happening.  Then I was interviewed in a conference room and we went 30 minutes past the scheduled end time.  At no point was I asked if I needed to be somewhere else or if I was okay on time.  SAD FACE.  

Cover letters, attire and courtesy e-mails
  • COVER LETTER: For each job I applied to, I tailored my cover letter extensively.  This is more simple to do than it sounds - read the job posting and try to speak to it specifically.  Think of examples of how you've demonstrated whatever the posting has asked for.  Get a real sense of what it seems is important to the company and emphasize those things.  One of the job postings I read said that people who work at that company are a little bit weird.  I literally added in this sentence: "I would love to sit down and discuss the details of my diverse research history and also measure exactly how weird I am."
  • ATTIRE:  I find that a safe bet for interviews (for women) is to wear a dress.  It's not too casual and you can still show that you have some personal style.  I wore a dress or skirt with a nice top and cardigan for many of the interviews.  For a few of them, I wore red jeans and a nice white top, with cute flats.  I justified wearing jeans for the companies that were startup-y and I knew that everyone interviewing me would be in jeans.  For the tech industry, you don't generally want to wear a suit.  Know your audience.  For the consultancy, I wore slacks and a nice top for one of the interviews, because they are client-facing and seem to dress up at work.  
Here's what I wore to several of the interviews.  I just put this on now, so my hair isn't did:

  • THANK YOU: After each round of interviews, I sent thank you e-mails to whomever I met with.  I asked the recruiter for the e-mail addresses, or if I could send my thank you's through the recruiter.  

Questions I was asked during the interviews
  • Tell us about a time when something wasn't going right at a project and you had to be flexible
    • This was the most common question I got.  I personally am not good at remembering examples of situations like this, although I know when doing Trial Consulting, I had to be flexible constantly.  So I didn't pick the *best* example, but instead the most recent.  
    • I talked about when something didn't go right at a project and what I did to adapt.  I also talked about debriefing after the project and what I could have done better.  Employers really want to hear about how you've learned from past experiences!  
  • What's your process for doing research?  
  • If we had X question that we wanted to answer, how would you go about researching it?
    • If there's not enough information, make sure to say "I'd want to get more information first, so I would meet with X to try and define the research question more specifically."
  • How do you keep up on the latest trends in the field?  What blogs do you read?
    • I rattled off blogs I read and I mentioned a specific one I like a lot, Dana Chisnell's blog, because I like that she specifically tells you HOW she does her research.  
  • What tools have you used?
    • I spoke about using Skype to screen share and iShowU to record a screen.  I also talked about tools I know about and would like to use but haven't because we haven't had the budget.  And I brought up using TaskRabbit for recruiting.
    • It's also good to talk about tools and skills you want to learn more about.  For instance, I spoke about how I'm interested in learning more about wireframing and design.

Questions I asked during the interviews
  • What are the challenges that this position faces?
    • You want to find out the real dirt about what is good and bad about the company.  You can also ask "tell me one thing you like about your job and one thing you would like to change."
  • Is the company bought in on research?
    • It's a good idea to find out if half your job will be convincing stakeholders about the value of research.  If the interviewers are asking you what the ROI (return on investment) of research is, then they might not see the benefits of research yet.  If you do get asked that question, try to talk about how research saves time because you are getting it right the first time, and time is money.  Research leads to better products and better products lead to more profits. 
  • What's the culture like?
    • This is where they start telling you about some of the perks, hack days, team outings, etc.
  • What's the work/life balance like?
    • This was something that was important to me! 
  • Can you tell me more about how the role takes in to account the needs of other stakeholders in the company?  
    • Will you be working with just the designers?  Or, will your role be more cross-functional?
    • Try to gauge the "politics" involved in getting research done.  In the end, are you just doing the research that the top stakeholders want you to do?  
  • Basically, just make sure you have a lot of thoughtful questions to ask!  Think about what is important to you and make sure you ask those questions.  Like I said before, you are interviewing the company as much as they are interviewing you.

Timeline of the entire process:
August 22 to September 4: Applied to jobs
September 14 to October 5: Interviewed
October 9 to October 12: Get offers and negotiated.
October 12: ACCEPTED A JOB!

I'm happy to announce that I accepted a job at Yammer.  I'll be starting the 29th (barring any unforeseen changes, and given that my background check doesn't yield anything unsavory).

If anyone out there has other advice on interviewing - what you wore, questions you were asked, etc. - please feel free to comment!

Thursday, July 12, 2012

Applying Some Nielsen Principles

Oh boy, it's been about a month since the last post!  Yet again, a lot has happened.

I went to another Design Research Support Group meeting - always fun and enlightening.  I brought homemade baked goods (cookies) again and have apparently set a precedent/developed a reputation for myself.  Must think of more things to bake to keep this going.  I also volunteered to host the next meeting.  I sent out the invitation with a warning about our dog MAYBE barking/growling as people enter.  Hopefully no one is scared of a 78 pound pit lab mix.

As per usual, I got some really useful tips out of the meeting.  One of the women had just recently started working at a startup and she posed a problem to the group.  She had done user research with 6 participants and wanted advice on how to present her findings to the engineers and not have them come away thinking "she only talked to six people?" and thinking that she probably just spoke to 6 friends.  The advice started right away from multiple people in the group:
  • Show the engineers the videos from the participants.  One guy from the group said that what he does is create a private Vimeo account and has the engineers log in and watch the usability tests.  Some issues become so readily apparent by just watching someone use the product.
  • Let the engineers know how the participants were recruited and that it's 6 participants, but that's 60 minutes times 6 people, which equals a lot of time and information.  
  • Do some mockups and wireframes to offer possible solutions so that you're not just telling the engineers all that is wrong.  Offer potential next steps.
  • Research shows that after 5 participants, the usefulness of getting more feedback tapers off.  Show Jakob Nielsen's graph (shown below) of why you only need to test with 5 users.  
We (the group) got an e-mail from the Researcher about a week later saying that she had presented her interviews/usability testing to the engineers and received rave reviews.  She showed them Jakob Nielsen's graph and edited a highlight reel of usability problems uncovered during testing.  The front-end developer asked her to add her recommendations to their project management tool.  It was her first meeting she had attended and she got some immediately useful/applicable advice!

Other things - the online Stanford Human Computer Interaction class has wrapped up, but I still have to catch up on a few video lectures.  The 5-week class went over a very wide range of topics!  Some were covered briefly, like typography, which I'm sure you could spend A LOT more time learning about.  I'm glad that I got a taste of so many subjects involved in HCI and overall, I think it was a great class.

Just to give you a taste of what else I've been learning, I recently watched a lecture about Heuristic Evaluation.  This was developed by Jakob Nielsen about 20 years ago.  I guess the theme of this entry might be Jakob Nielsen.  Heuristic Evaluation is less expensive than User Testings, since you use a small set of evaluators (3-5).
  • Evaluators examine the UI independently and check for compliance with usability principles ("heuristics").
  • Different evaluators will find different problems.  A single evaluator achieves poor results and only finds 35% of usability problems.  Five evaluators find 75% of problems. 
  • Evaluators only communicate afterwards.  Findings are then aggregated.
  • This can be performed on working UI or sketches. 
  • The evaluators step through the designs several times.  They examine the details, flow, and architecture, and they consult a list of usability principles. 
From what I can tell, Heuristic Evaluation is very similar to "Expert Review" except that Expert Review may be more holistic and qualitative and takes into account the expert's own personal experience.

In other news, I'm still off and running with Shoefitr.  We've been conducting user interviews, concept validation, and we have even intercepted people on the street and in shops to ask them to look at our designs and give feedback.  Learning a lot!

Wednesday, June 13, 2012

Stanford, Startups, and Meetups

A lot has happened since I started this blog!  I started taking a free Human-Computer Interaction class online through Stanford.  I am in Week 3 of the five week course and so far I think it's really great.  I'm learning a ton on many subjects: the history of HCI, research methods, prototyping (low fidelity vs. high fidelity), needfinding, and mental models.  My favorite subject that I've been learning about is paper prototyping.  Basically it's arts and crafts time.  You can get creative and use a wide array of materials like paper, cardboard, transparencies, poster board, tape, glue, sharpies, index cards, and so much more.  In my spare time, I do screen printing and cross-stitching, so this process really appeals to me.  In case anyone was wondering, the bicycle background of this blog is actually a cross-stitch pattern I am working on.  You can create a paper prototype of practically anything whether it be a website, iPhone app, console, etc.  Another fun thing is that you can cut out the widgets and during user testing, as participants "press the buttons," you can place the correct widget (like a pull-down menu) on the prototype.  Paper prototyping is a great way to invest a small amount of time and money and start getting feedback.  It's good to use early in the design process.  If your prototype is in paper format, it is still very easily changeable.  I'm excited to start paper prototyping the UI for an iPhone game I'm working on.  This is a great way for me to communicate ideas to the rest of the team and think out what needs to be included in the design.

I opted to do the "Apprentice Track" of the course where I do not turn in homework, but instead only take the quizzes.  The reason I don't want to do the homework is that I have some real-world projects I can apply what I'm learning to, so I don't want to spend the time on homework.  Which leads me into the real-world stuff I'm working on...

I have started working part-time at a startup called as a User Researcher.  Yay!  I plan on doing this over the Summer (at least) so that I can learn as much as I can and gain experience.  It's been about 2 weeks and I'm already learning so much.  I've worked on writing a script for a semi-structured interview and I've also helped design and implement a card sorting task.  Card sorting is basically what it sounds like.  It's a technique that's used to uncover how people organize information and how they categorize and relate concepts.  Card sorting tasks include giving a participant cards with information on them.  The participant is then given instructions to organize those cards.  This could be in a way the participant decides, or the participant could be given guidance to place the cards into existing groups.  Or it could be mixed.  This is really good for figuring out how people organize information and it informs how designers will then organize information on a website, for instance.

Last, but not least, I went to another User Research meeting.  This time it was in the South Bay, hosted by one of the members who works at Google.  It was nice to see the Google campus in Mountain View (and eat dinner!).  It was once again a great night filled with warm, friendly, and passionate people.  A research method that I had not yet heard of was discussed, participatory design.  It is an iterative design process that uses focus groups to outline needs, task analysis to inform specifications, and user advisory boards to maintain user input throughout the development process.  And it sort of relates to the paper prototyping method I was talking about earlier.  The group talked about experience using participatory design and a couple of people shared tips:

  • Use black and white, crafty looking sketches, like wireframes, to give to the groups.  
  • Give the participants sharpies; make sure they keep away from small details. 
  • Have small groups work together drawing, moving widgets/pieces of a menu, and discussing what is working for them. 
  • Small groups come together as a bigger group.  
  • Use icebreaker questions before having people show/share their ideas.  
Someone also brought up participatory critique.  This is another method where you give participants a simple wireframe mockup and red and green highlighters.  They then critique the mockup with their highlighters and talk about what is working and what isn't.

Well, that's all for now.  Turns out that I have a lot to blog about and it looks like that won't be stopping anytime soon.

Monday, June 4, 2012

User Researcher Meetup #1 - Tools of the Trade

As I mentioned in the previous post, Beth invited me to a User Researcher group, and the next meeting just happened to be at her house!  This was a few weeks ago (I'm already behind on posting).  I brought vegan cupcakes, a bottle of wine, and my notebook.  I had a really great time at the meetup.  It was such a warm and inviting group of people - mostly women and one guy.  I truly appreciated the supportive atmosphere.  The goal of the group is to get together in an informal environment and talk about issues raised while doing research and also to get advice from your fellow researchers.  The first thing we did (after settling down from small talk and grabbing snacks/drinks) was go around the room and introduce ourselves.  Some people were from large companies, some freelancers, some from consulting agencies, and some from small startups.  It really was a great mix of researchers and it was interesting to hear how people got into research.  Many "fell into it" in some way from other fields like Marketing, Design, and Customer Service.  When it was my turn to say who I was, I was so happy that I was received so well!  People found the industry I was coming from  (jury consulting) fascinating and wanted to know more about it.  Since I'm not technically a User Researcher, I was grateful that I was immediately accepted and told that I'm on the right track already.  I also went ahead and took that opportunity to throw out that I would love to get some work experience (magic word, for FREE) if anyone knew of an opportunity.  One hand immediately shot up - more on that later.

We spoke about many different subjects during the meeting, including how researchers synthesize data.  One researcher had attended a workshop put on by Dana Chisnell (Dana's blog) and she talked about the method she learned.  At the workshop they performed an "affinity diagramming exercise" where the group:

1) Brainstormed on post-it notes
2) Grouped similar post-its together (stacked in a column, order doesn't matter)
3) Labeled each group with a different colored post-it with the theme heading
4) Voted (votes written directly on the theme headings), tallied up votes, and then prioritized each group

Before brainstorming, they made sure to have a clear focus question, grounded in observation and real data, not opinions.  Another very interesting part of the exercise was that there was no talking!  Everyone silently went to the wall and paired post-its together, and then found pairs that go together, and so on.  Then everyone silently voted on the different themes, which is how the prioritization was decided.  I think that's a good idea because without the talking, I'm sure things moved along more quickly and there was less influencing going on.  It sounded like a great workshop.  I'd be interested to attend one myself.

We also talked a bit about the favorite tools used by the researchers for different tasks.  One that I thought was really cool was the Live Scribe.  It's a pen that also records audio.  It also sort of makes notes on the audio with what you write...if that makes sense.  You write in a special notebook and let's say you're listening to a specific talk at a conference.  You write down the subject of the talk when it starts.  Later, to hear that audio from that talk, you simply tap with your pen on the title of the talk, which you wrote down in your special notebook.  It's linked to the time signature of the audio and will start playing what you were listening to when you wrote down whatever it is you wrote down.  That all sounds confusing.  Maybe you should just visit the website linked above.  The user experience with the pen is pretty interesting as well.  If you want to e-mail yourself your notes, you write "email" on your paper and then tap your pen on each page you want to send.  Every function you want to perform, you write/draw.  I could see this being extremely useful when interviewing a user though!   I want one.

The group spoke about different methods for videotaping users and remote user testing.  Here are the different methods discussed:

  • One of the researchers just uses his iPhone and puts it on a tripod.  He researches usability of a mobile app.  He has the iPhone set up close to the user so that the image is of the user holding the mobile device from her own vantage point.  
  • Hugging a laptop is another method for seeing what's happening on a mobile device.  The user turns the laptop's camera away from herself and "hugs it."  She then holds the mobile device  out in front of her so that the laptop camera records what she's doing.  
  • There's an app out there called Reflection, which mirrors what is happening on the screen of your iPhone, iPad, or Mac.  It's, as you may have guessed, only for Apple products right now.  Also, you don't see the gestures, just what is happening on the screen.  And you must be hooked up to wifi for it.  
  • ScreenFlow can be used for recording what is happening on a screen.  
  • For remote user testing, GoToMeeting, is an online meeting tool that can be used.
  • Another site good for user testing is a meeting tool where you can share your screen, Join.Me
It was a great night and chock-full of useful information!  Oh, and I did end up making an amazing contact that night.  I spoke to Andrea after the meeting - she is the designer at - and we talked about me helping out at Shoefitr!  But that's a whole other post.

I'll leave you with a picture of me hugging a laptop.
And here's the laptop taking a picture of me holding my iPhone, which is also taking a picture of me hugging my laptop.  So meta!


Monday, May 21, 2012


A couple of months ago I had my first interview for a User Researcher position.  The job was an Internship with ModCloth, a great way for me to break into the business I thought.  My previous work conducting research got me an interview.  Although I did not end up getting the position, the whole experience turned out to be very rewarding.  

Since I had never had an interview in this field before, I didn't quite know what to expect.  I had researched the company, thought up what questions I had about the job, and did my best to think about how my previous experience related.  I also tried to think of scenarios (my most feared question), like a time when I faced conflict and how I dealt with it.  The questions I didn't expect, but should have, concerned how I was educating myself about User Research and how I keep up-to-date with what is going on in the field.  I had read a few blogs before, but did not remember what they were called.  I'd done some research on what the field was about, but I had not gone the extra mile to really school myself.  I needed to get serious and I had some homework to do!  

One of the women I had met with at ModCloth was Beth Lingard, the User Experience Research Manager.  I reached out to Beth (she had made it apparent that she'd be open to that during our interview...she was SO NICE!) a few weeks later and we ended up meeting for a drink after work.  We had an informational meeting where I got some GREAT advice, direction, and more homework.  I asked Beth if she had any books, blogs, and tips she could recommend for me to get started in learning.  Here is what Beth recommended to me:


  • Observing the User Experience: A Practitioner's Guide to User Research by Mike Kuniavsky (I've since learned that many User Researchers consider this book to be an incredibly useful reference - it's still relevant after many years)
  • Understanding Your Users, also by Mike Kuniavsky (Beth mentioned that getting just one of Mike K.'s books would probably be sufficient, so I only have the former as of right now)
  • A Project Guide to UX Design: For User Experience Designers in the Field or in the Making by Russ Unger & Carolyn Chandler
  • Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems by Steve Krug
  • Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug

People/Organizations to follow on Twitter:

Beth also recommended a number of blogs, and I believe all of them are showing up as links to the right of this blog (in addition to a couple of others that I've found).  She also recommended liking the Facebook page for Tomer Sharon's book "It's Our Research."  On both the Facebook page and his twitter, he shares videos of interviews associated with the book.  

Other advice/tips
  • Be part of the conversation.  Follow people on twitter, tweet, re-tweet, blog (check!) - read what people in the field are getting ramped up about, comment on it, listen to opinions, give opinions. 
  • Participate in research studies.  Beth actually gets research participants from TaskRabbit occasionally.  I think that is a brilliant idea for me to sign up with TaskRabbit and see if I can be a participant in a study or two.  This would give me in-person insight into methods. 
  • Go to meetups, talks, workshops.  There is an organization called BayChi - CHI stands for Computer-Human Interaction - which is a great resource for professionals in the bay area.  I recently submitted my application to be a member (it cost $20 for the year), so soon I'll be on the list serv and I'll also have access to their Job Bank.  Beth also very graciously invited me into a group of UXR professionals who meet once a month to mingle, share ideas, and sometimes commiserate.  And the next meeting just so happened to be at Beth's house!   
  • Set up as many informational interviews as you can.  Ask different people at different companies (startups, big companies, consultancies) how they do research. 
  • Freelance.  Gain experience.  I'm hesitant to tell someone else to just go work for free - your work definitely has value, even if you are new to the game.  If you are spending the time to learn something that someone else doesn't have time to learn, that's worth something!  I've recently gone part-time at my jury consulting job, which has freed up my schedule a lot.  I'm also financially able to do some free work at this time in my life, so if the right opportunity comes along (even if it's working for free), I don't think I will pass it up.  But that's just me.  People need to eat! 
  • Start in customer service at a startup.  Beth emphasized to me that talking to the customers is the first step in User Research.  They are a valuable resource!  Since people tend to wear many hats at a startup, starting in a customer service role could be a great way to eventually start doing User Research for your company.  Beth talks about her startup roots and gives some other great advice in this article, "Dispelling 4 Myths of User Experience Research at Startups" 
Other Awesome stuff I learned from my informational with Beth:
  • People in general are nice and decent and willing to help you.  Beth told me that she considers many people, who have helped her get where she is, her mentors.  They don't necessarily know that they are her mentors.  So - go collect yourself some mentors!  They don't even have to know!  
  • Have confidence!  Half the people in the field are winging it.  You don't have to know EVERYTHING about EVERYTHING, just be inquisitive and passionate.  Beth made me feel really good by teling me that just by reaching out to her, I've taken a big step.  She also gave me confidence that I have what it takes and I'm gonna make it happen.  
  • Since the meeting, I've been reading up a storm.  As I learn more, the concepts seem way less daunting.  I'll look up a term and be like "oh, that's what that is."  Like Steve Krug said, it's not rocket surgery. 
Okay, I'm ending this blog entry with one other really awesome thing that happened during that ModCloth interview.  I met Winston, the Mod Dog Mascot! 

Stay tuned for my next entry where I'll recap what I learned from my first UXR meetup.