“I heard about a need in the UX community, and I decided to meet it.”
This quote pretty much summarized the inspiration behind how the newest UX meetup group in Dallas got started. UX Research and Strategy, now just over a month old, has had one successful event so far, and continues to grow.
I regularly attend meetups, and while attending those, I heard repeatedly that attendees wanted more resources on UX research. They wanted to learn about different methods, best practices, how to “sell researcher to executives,” and other topics along those lines.
So I reached out to a couple of former co-workers and fabulous ladies, Lauren Singer and Lorie Whitaker to see if they were interested in helping me create a meetup group focused on UX Research, and with Lauren’s suggestion, Strategy too. They thought it was a great idea. First we crowd sourced the idea, to test that it was a valid concept. We posted the idea on LinkedIn to gauge interest in the topic. We got a lot of positive feedback and interest so we decided to move forward with the group’s formation. Thus UX Research and Strategy was born.
Our first meetup was held at Lifeblue in Plano. Our generous hosts provided food and beverages as well as an amazing view from their 12th floor balcony. Crazy storms rolled through just a couple of hours before our event was supposed to kick off. We were not sure if anyone was going to show up. No one wants to drive in monstrous thunder storms. But by the time the event started, the storms passed, the skies cleared, the temperatures dropped (a very good thing in Texas) and the crowd started rolling in. We had nearly 50 attendees which made our first meetup much more successful than we anticipated. Woot!
We first started the night with introducing ourselves and the group. We shared the group’s mission and motivations. Then we asked the attendees to participate in an exercise with us. The leaders of UX and Research and Strategy wanted to make sure that this group is meeting the community’s needs. This goes back to the original ask of what people felt was lacking in the UX community, and how we can fill that gap. What better way to get feedback on the group then have the members brainstorm the direction the group should go?
We asked the members to break in to smaller groups to come up with their hopes, fears and ideas for the group. Again, we wanted attendees to weigh in and help us shape the topics the group would cover through 2019 and beyond.
Everyone was happy to participate in this brainstorming activity. After the groups explored the fears, hopes and ideas for the UX Research and Strategy groups, we then recorded some of the highlights in a shareout so that all attendees could hear the fabulous ideas people had.
We wrapped up the night with a bit more networking and idea exchanging. What were the leaders of UX Research and Strategy planning on doing with this information? Planning out all of our future events, of course!
If you would like to stay on top of what the UX Research and Strategy group is up to, be sure to connect to us on LinkedIn. Also follow the group on Eventbrite to see all of the fabulous events we have happening in 2019 and beyond.
I recently attended a Ladies that UX Fort Worth event where Kayla Wren covered the topic “Rose Bud, Thorn.” This research method is designed to surfacing three things: the good, the bad and opportunity and insights. I thought that using these lenses was a rather interesting perspective, so I thought I would share the method with you today.
What is the Rose, Bud, Thorn method?
Rose Bud, Thorn is a “Design Thinking” activity that can be used to uncover and surface insights for a number of topics. It’s a way to proclaim what exists now, as well as explore ways for improvement. Basically, this process asks you to look at something from three different perspectives:
Rose: Something that is positive or working well
Thorn: Something that is negative or not working well
Bud: An opportunity or area for improvement
The “Rose” of this process is a way to showcase the good things that are going on. Hopefully not all things are bad. The “Thorn” is the bad parts of the process/app/etc. You must be authentic and recognize that not everything is perfect, and it is critical to discuss what needs improvement. The “Bud” of this the gold mine because this is where you surface ideas and potential improvements.
You can use this method to explore a number of things. It could be reviewing a process, like traveling on an airplane or onbaording a new employee. You can review an app or enterprise software. It can even be a future concept or something that is not even real yet, like how you might envision a new policy or idea.
Why would a person do this?
There are many benefits of this of this procedure including:
It is so darn simple.
You do not have to be a deep subject matter expert on a topic to participate.
Nor does it take any technical knowledge to work in this method.
It’s super low-fidelity, so no computer hookup required.
Only a few supplies are needed: sticky-notes, markers and a wall or whiteboard to accumulate the thoughts and ideas.
It can be done in-person in any office or online on an electronic whiteboard like Mural.
You can do this activity with a larger or small group of people.
Who can do it?
Anyone! Of course that is the answer you were expecting, right? Really though, this activity can be conducted by people with any skill levels. You can go through this process through members of your team, or with external clients. Rose, Thorn, Bud can be among students or professionals. All age levels. All levels of expertise. The more diverse the perspectives the better.
If you are working with a large group of people, it might be better to break this larger group in to smaller, more manageable clusters of participants.
How do get ready?
First, decide on the topic. Then determine if that topic can be broken in to phases or chunks so that the activity can be organized in to smaller, manageable portions if needed. Also determine if the problem is too large for this activity. It might need to be refined so that you are focusing on the right part of the problem you would like to explore for improvements.
Then decide who should participate. Are there subject matter experts who can bring expertise to the brainstorming session? Are there customers who can bring a unique perspective? Who from the team should be included? Developers? Designers? Product owners? Anyone else? Like I mentioned before, the more diverse perspectives you can bring to this process the better. This is a time to brainstorm and come up with a lot of ideas. So give your opportunity to do so with a variety of perspectives. Though, if the group gets too large, it might be better to multiple sessions, pending budget and time constraints.
Next deal with the logistics. I won’t get in to those details in too much depth here because those will vary on your circumstances. Keep in mind basic best practices when conducting any research session:
Define the goal of the research. Also understand the hypothesis and the reason(s) you are conducting the research.
Make sure that you are meeting the stakeholders’ and requesters’ needs and ask.
Plan ahead of time and make sure you are organized and ready for the session.
Run a pilot and make sure the plan that you have runs as smoothly as it can.
How do you do it?
Let’s fast forward to the day of the session. You already have your topic, participants, venue, etc. Now let’s talk about what you will need to do.
Whiteboard or wall for post-it notes
Sharpie markers for each participant
Three color of post-it notes. I recommend pink for Rose/Good, green for Bud/Opportunity and yellow or blue for Thorn/Bad.
Optional: voting stickers for the participants to vote on the Bud/Opportunity that he team will work on to implement or research further
A whiteboard segmented in to topics you would like the group to work through
Talk to the group about the goals of the research process. You want them to be honest, open and creative. Tell them about the topic we are going to explore today and how we are going to explore it through three lenses: the good, the bad and the opportunities.
Overview of the process
Grab three different-colored post-it pad for the phase we are on (pink for Rose, green for Bud and blue for Thorn) and a sharpie marker.
Step up to the board and start with the (first of however many you have) portion of the process you want to brainstorm about.
Take 5 minutes to quietly brainstorm the good and bad aspects of that process, as well as opportunities, by writing on the different colored post-it pad. Don’t forget to change the color of the post-it you write on based on whether or not is was a good point, a bad point or an opportunity.
As you come up with an idea, write it down and then verbally state what it reads as you put it on the board. This is done so that you can inform others of your idea. Plus it might prompt other people to think of something related or different to what you wrote.
Populate the board with as many good, bad and opportunities as you can in in 5 minutes. Don’t start side conversations or dismiss any ideas. This is the time to brainstorm as many ideas as you can and then capture them on the board.
If the group is still going strong, give them another minute or two to get all of the ideas out.
When the time is up, have the group cluster the post-it notes in to themes and similar ideas.
Let the group take a few minutes to reflect on these themes and have a short discussion about what data has surfaced from the exercise.
Are there surprises?
Are there repeated problems?
Are there issues that are present, have been for a long time, but don’t ever seem to be fixed?
What are the opportunities?
Any great ideas?
Any opportunities that could be easily accomplished? Low hanging fruit?
An optional next step is that you have the group use stickers to “vote” on various opportunities to determine what the group should work on first.
There are so many aspects of Design Thinking. And there are so many ways to build empathy for the user and generate ideas during discovery. Rose, Thorn, Bud seems to be an easy method that provides an opportunity for your group to surface several opportunities for improvement. Don’t be intimidated by this method if you are nervous and feel like you do not have extensive experience to conduct or participate in such a session. Just go for it. If you do try the Rose, Thorn, Bud method, please let me know how it worked for you and what opportunities your team has discovered to work on.
To read more about the method, I found another interesting website that breaks down how to do it on Atomic Object’s website.
This past weekend was a busy and productive weekend for me. I participated in my first Dallas Give Camp. What is Dallas Give Camp you might ask? Dallas Give Camp is an annual event where professionals ranging from UX designers, business analysts, project owners, developers and other technology-related professionals come together with non-profit organizations to design or redesign the organizations website.
Dallas Give Camp’s Mission:
“We support our communities by bringing together motivated volunteers to dedicate their professional expertise, deep insights, and individual talents to further the missions of local charitable organizations through the applied use of knowledge sharing, technology solutions, and innovative design.”
It’s a jam-packed weekend starting Friday evening at 5 p.m. and ended Sunday evening at around 4 p.m. Yes, you do get to go home and sleep. It’s not one of those all-nighter type hackathons (Thank goodness. I am too old for those. Ha!) But I was there, fully-invested for each hour and minute.
What was my assignment?
I was the UX designer helping redesign the Dallas Goethe Center’s website. I’ll refer to the organization as DGC for short. The DGC is a local organization that promotes German language learning and culture in North Texas. They have two primary audiences: students and parents of students who want to learn to speak German, and members who participate in the cultural events.
What was my role?
As the UX designer, I worked with the team of developers to come up with a technology solution. I also worked with stakeholders to surface DGC’s problems, pain points and needs to understand what they wanted out of the new website. Also, I helped make sure that the project was moving forward, all pages and components were being built, and the content was being added to the pages.
What was the problem?
Their current website platform was on Drupal, and they wanted a platform that was easier to work with. That new platform was WordPress, which is what Dallas Give Camp encourages all teams to work on. Drupal was difficult for DGC’s Drupal-challenged volunteers and staff to update. It was also technologically limited, restricting features like easy “customer shopping” and website customization. The Divi theme on WordPress would help with org overcome these challenges.
How did I get started?
As with any good UX designer, I wanted a better understanding of the problem. The week before Give Camp, I talked with three members of the DGC staff to get their perspective of the website. We talked about reasons why customers come to the site, their pain points and goals for the new website. I wanted to do this initial research to get different perspectives on how the website could be improved.
What was my challenge?
I was very new to the Divi theme and have very little experience with WordPress. My experience is pretty much just posting stories to this lovely blog. Nothing too fancy. So I am not in the regular practice of building out pages or components within WordPress. I needed a tutorial quickly on how to work in the Divi theme, where to find things and how I can get up and running asap. I will say, I am really spoiled in working within WYSIWYG programs like Sketch.
How did I collaborate?
I worked with developers to understand our technology constraints. The devs also helped me understand Divi themes, WordPress and basic CSS. Thank goodness I had a basic knowledge of code. It did help me customize things a bit – once I found out where to do that within the Divi theme interface. I also worked with several stakeholders from the DGC who were our on-site subject-matter experts. It was wonderful to have them on site, right there to answer any questions we might have at any moment. The best part is the staff members from DGC were at Give Camp from the start of the day until late in the night. They were just as committed and involved as we were.
We started Friday evening, with a hearty dinner to get us ready for the first night of the event. We met the team, broke down the problems and prioritized the major issues we needed to solve. We talked about what aspects of the website needed to be improved, what new pages we needed to create and we were introduced to WordPress and the Divi them. But the end of Friday evening, at 10:30 p.m., we had a pretty good plan of the site map, what pages we needed to build and what elements would go on those pages.
Bright-eyed and bushy-tailed, we all rolled in around 9 a.m. ready to build out the site. I wrote the site map on the whiteboard so that we could verify that we had all of the content included. I also started sketching out some basic wireframes to further validate that all content was accounted for. Then it was time for me to get to work.
Like I mentioned earlier, I was pretty inexperienced with WordPress, and had no previous knowledge of the Divi theme. So I was pretty slow to jump right in and churning out components. That is what I wanted to do. I am so used to just being able to build things at a pretty hefty speed in Sketch. But this proved to be much more challenging than expected. I wanted to get pages build and templates ready ahead of the team so that they could just plug and play.
A number of pages had 3 cards, in a box, of content to lead the page. I wanted this component to be built and ready to go so that it would be consistent across all instances. But it took the developer and I over an hour to get it built to (near) the specifications I had in mind. Yes we got it built, but it ate up a lot of time. Yikes! Now we were approaching early afternoon and time was pressing against us. We had a lot of pages to build. We had to get components like boxes, buttons, purchasing options and other website elements on the page. We had to get all of the content on those pages. The content was all really, really long, so we needed to edit that content down to digestible chunks. Then we needed to apply some design style to improve the design beyond the basic offering.
Well, shit started hitting the fan in the early evening. We were very behind. We still needed pages built, components added, content added and interactions tested. We started to panic. Well, I did. We did not know who was working on what. We were not really sure what was and was not finished. It was a mild case of chaos.
We called in some help. A floating developer came in and assessed the situation. We had not been using Trello. Hence, we did not know who was assigned to what part of the project and how that was progressing. So we got all the remaining work on the board. That way we got a bit more organized and figured out who was responsible for what. By 10:30 at night, we were running on fumes. We finally got all the pages created, components on them, and basic content on most of them. We had not adjusted the style from the out of the box offering. And we had not even begun to test items like links, shopping cart functionality or other interactions. But that was OK. We still had a few hours on Sunday to do our best to make it to the finish line. At least now the fire was contained.
Bright and early again. It was a calm atmosphere, coming to terms with the fact that not all of our to-do list was going to be complete. Content was on the pages, but it still needed to be edited. Style was not going to be modified, but it was pretty good looking for now. Links and buttons were going to be tested. The shopping cart experience was working. We were very close to a functioning website. The stakeholders were very pleased with the progress we had made in just one weekend and were very excited to launch. We were 90 percent to complete success. And 90 percent is not only good enough, it’s pretty damn good.
We wrapped up the day updating the Trello board with tasks that still needed to be completed after Give Camp. We all gathered again for all of the Give Csamp teams to share their stories and display their much-earned success. We had built a website in just one weekend and it was pretty kick-ass.
What did I learn?
I need to get ahead of the game: I should have worked on the design solution earlier and started constructing wireframes, mockups and structure.
I need to learn the technology: I should have looked in to Divi a bit more. I should have learned the capabilities before hand and thought about how I wanted to tackle some of the design challenges.
I need to track the progress: We were assigned a Trello board well before kickoff, but we quickly abandoned it in the midst of the chaos. But there’s a reason why they gave us access to Trello, and we should use it. Tracking our progress on Trello got us back on line and better organized.
I can do it: I can pick up new technology. I can work with a new team. I can get a lot of work done in a short amount of time. I can establish a good comradery with a team and help us get to a common goal. I can do it!
Would I do it again?
Hell yeah! Maybe not for another year. But yes I would do it. It was fun to work on something different and get fully emerged in the website design process. It was great to have stakeholders on hand who were willing to get their hands dirty and pitch in to get things done. It was exhausting to put in so many hours straight. But it was exhilarating to jive through and get it done. Most importantly, it felt really great to contribute my skills as a UX designer in a positive way and to give back to the community in some way. Working with Dallas Give Camp and the Dallas Goethe Center was professionally and personally rewarding for sure. Sign me up for next year – after I get a bit of a nap.
Q&D is a term I would hear told to reporters from my days working at daily newspaper. It stands for Quick and Dirty. And it’s a type of story that reporters are requested to write quite often. Just turn in a quick story to help fill the pages of the newspaper. It doesn’t have to be in depth; it doesn’t have have to be a Pulitzer-prize winning piece; it just has to be done.
I think we have all heard the request to turn something in ASAP. It’s not only the nature of the business world, but it certainly is the nature of the the UX world.
“We need to just get the results to the group so we can move forward.”
And it’s requests like this that cause UX professionals to produce their own Q&D.
Recently I was researching a very manual process. This process was creating reports for customers. There were many steps involved in this process. The funny (or sad, actually) thing is that no one really knew how many steps were involved in this process. Not even the person creating the reports. That is, until I conducted my research and mapped out the process in detail. Wow it is a tedious task!
So after several side-by-side observation sessions and interviews, I had a strong idea of what the report-building process consisted of. I needed to share these findings with my development team – and fast! Enter the not-so-pretty results. Wah wah.
Thus, we come to the point of this story: Results don’t always have to be a work of art. There are situations when you don’t don’t have time to create a beautiful journey map. You can’t create a high-fidelity deliverable, spun from a program like InDesign, because you need to share your results fast. So what do you do? Deliver the deliverable that gets the job done.
So what is a gal to do? Create the journey using a spreadsheet like Excel and get that to the team as soon as possible.
There are a few advantages to a Q&D deliverable:
Easy to put together.
Can be done rather quickly.
Can share with members of the team in a format they can easily read.
Others can even make edits to the spreadsheet if needed.
It’s a living document, and if there are changes that need to be made, they don’t have to be made through you.
Getting this deliverable off your plate frees up your time to move on to the next project.
Sure this spreadsheet is not going to be a design portfolio piece. But it does the job. This journey map communicates the process, resources and tools used, as well as time on task. This is all important information. And now it is in the team’s hands as an action item. They are not waiting for me to produce a “pretty” piece of design. In the end, my research is moving the project forward more quickly and accurately. Sometimes you just have to do what you’ve gotta do to get a job done.
There are several ways that you can do a better job of understanding your user’s needs. Understanding what your user really wants starts with research. There are a variety of quick and easy research methods every UX designer can use to understand their users better.
Get users to complete a diary to give you insight in to their world.
Interview users to better understand the problem you are trying to solve. Make sure you are solving a real user problem.
Find the “job” people hire your “product” to do.
Ask for a story about the user’s context.
Have the user create a photographic “Day in the Life” of their work area to understand their environment more.
Learn “trigger” words. Trigger words are simply words used by the user. It might be useful to include some of those trigger words in your product or website. Speak the user’s language.
When it comes to user experience research, there are several methods to gather information. One of those research methods is a survey. Now, a lot of UX researchers might frown upon the use of surveys. It’s true, they are a great way to gather quantitative information. And that is great to gather in a lot of circumstances. But when it comes to user experience, quantity is not as important as understanding the “why” someone does something. That is the value of qualitative research over quantitative.
So a lot of “pure” UX researchers choose to not even entertain the idea of sending out a survey. I think this mindset is because a survey may be an opportunity to gather some insights, but they are not always very helpful insights. And for those who don’t know any better, a person might interpret these survey answers as gospel. Again, they don’t provide the “why” someone is doing something.
For the survey portion I am sharing above, I used a survey as a supplement to a recent empathy interview session I performed. I was interviewing people on their recent car-purchase journey. Instead of asking participants what kind of car they bought, or what automobile features were of the utmost importance, I chose to gather some of this information in a survey. I gave the participant this survey to fill out before we had our interview. And in case you are worried, I did ask a lot of the same information about why they bought a car so that I could dig deeper in to the “why” they bought what they did. Also, this gave me an opportunity to see just how consistent people were in their answers. Thankfully all of them were.
So, the lesson here folks is that as a user experience researcher, don’t completely rule out a survey. You can gather a lot more information you might not have time to find out in just an hour interview. Remember, as a good researcher, you should have a lot of tools in your tool kit. And yes, a survey should be one of them.
Have you ever interviewed a user, after the fact, about an experience and they had nothing but positive things to say about it? But you know that they struggled or had pain points along the way. This phenomenon has a name, and it’s known as peak–end rule.
What is the peak-end rule?
Peak-end rule is a phenomenon where people judge an experience largely based on how they felt at its peak. The peak is the most intense moment. In other words, they forget about all of the feelings and emotions they were experience throughout the entire event. And thy seem to just “remember” how they felt at the peak, whether that is good or bad. This model dictates that an event is not judged by the entirety of an experience, but by prototypical moments (or snapshots) as a result of the representativeness heuristic, according to Wikipedia.
Why does it happen?
The peak-end rule tends to happen more on emotional events, even though people are not usually aware of their motional involvement at the time. Also, people tend to remember how things turned out overall. If they had final success in the process, then their memory is going to be more positive and they tend to forget about the struggles they had along the journey. People just tend to think more positively of themselves when they have accomplished something, and therefore forget the negative aspects. One way to think about this is, if people think too much about it, and focus on the pain they went through, then they are likely to feel that pain again. So perhaps this is a instinctive defense mechanism? Without obtaining a psychology degree, I will leave that question open for debate.
How can you avoid it in your research?
The best way I can think of avoiding the peak-end bias is to observe participants in real time instead of relying on their account of it after the fact. This is why ethnographic research is so important in User Experience design. People are not even aware of some of the actions they perform. But if you are there to observe them in person, you discover all sorts of nuggets in behavior the user might not be aware to share. When you observe a participant, you see things like pain points, struggles, repetition, redundancy, mistakes, hacks, work arounds, cheating, confusion and all sorts of gold nuggets of user behavior.
I have seen it time and time again, a participant is trying to complete a task, and the software or website they are using does not perform as expected. The participant is frustrated. Maybe she expresses a slight sigh in displeasuer. Maybe she even tries to accomplish the task in a different way. Maybe she concedes and relies on the “hack” she has created as a work around. When confronted on an obvious frustration, she makes comments like:
Oh what to you mean? Did I make a face? I didn’t even notice.
I always have to do this.
It’s no big deal, it’s just part of the job.
These comments are a tell-tale sign of actions that would likely not be reported in an interview after the fact.
The bottom line: Get out of the building and observe your user first hand. You will get much more context witnessing them in their environment rather than just “taking their word for it.” Observation is king!
Seems like everyone has a year in review. What celebrities died this year? What were the biggest news stories? What can we expect in 2017? Well I am not going to recap all the biggest news for 2016. Instead, I would like to reflect on the crazy year it has been for me and to see if I actually accomplished ANY of my goals. ha ha.
To start with, I took a look at my mid year post “Mid Year: Revisiting My Personal Goals” to see how my goal accomplishment were stacking up there. Well, as you can see from the article, I missed few and hit a few. That’s ok, because my career to a huge shift in the middle of the year that caused me to quickly start a new job and move across the country.
Re-learned Axure. I did, but I have not practiced it as much as I should have so I probably forgot a lot of the actions.
Continue writing blog posts. I wanted to hit 30 blog posts this year. I am pretty sure I did that. I want to continue this practice in the new year.
Join a side project. I helped out with Wingspanarts. As of today, the site has not launched their redesign. But I hope they will find a great developer and do so early in the new year.
So those were my major accomplishments. My list was much shorter than I hoped. But I am OK with that. Like I said, I had some major career shifts this year and I needed to focus on sharpening new skills needed for the job. My plan is to think about my new goals for the new year and write a post soon.
Until then, I hope you had a wonderful year. I hope you accomplished some goals, and don’t beat yourself up about the ones you did not knock off your list. There’s always next year to revisit those goals and to make new ones.
Like we all know in UX, it is ok to learn from your failings. Also, it’s ok to pivot in your goals when life hands you changes. Just go with the flow…in 2017.
I recently had the opportunity to practice a research method that is often used to help organize a website’s navigation. Card sorting is a research method used to help structure a site, product or other system. Card sorting helps you to get better insight in to the user’s mental model, as well as how they expect things to be structured and organized. I have written about my experience using card sorting before in another article titled, “UX Deliverables: Card Sort.”
Today I want to discuss using card sorting as another way of understanding how users organize information. Again, card sorting seems to be primarily used to organize navigation. In this study I used card sorting to have customers prioritize and sort education topics based on their interest in that topic. In other words, I had them show which topics they had an interest in, and those they did not.
“Card sorting is a user-centered design method for increasing a system’s findability. The process involves sorting a series of cards, each labeled with a piece of content or functionality, into groups that make sense to users or participants. http://boxesandarrows.com/card-sorting-a-definitive-guide/
A customer is signing up for a new loan account. This is a great opportunity to give them more information about loans and finances. We wanted a better understanding of the types of information a person would want in the onboarding process. And as important, we wanted to know the types of information a new customer did NOT want.
No need to get all fancy and high tech. The great thing about card sorting is you can do it in the dark – well sort of. You don’t need a computer to gain great insights from your participant. Just use some index cards (or regular paper) with words or phrases typed or written on them. Have a flat surface where the participant can lay out the cards. Have a few extra blank cards and a marker just in case the person wants to create new cards. This happens more than you would expect. Do your best not to provide too much information or any definitions because you want to simulate a natural experience. In the context of her home, she would not have anyone explaining the terms to her. So we need this situation to be as realistic as possible.
Present these cards – in no particular order – to the participant and have him/her organize them in to categories that make sense to him/her. In this case, the categories were predetermined for the participant, but then he/she could create more if needed. In fact, in this study, one participant did create his/her own category. While the person is sorting out the cards, encourage him/her to talk through the process and explain his/her rationale. It’s this information that is actually much more valuable that the final results in many ways. To get a better understanding why he/she is putting items in to groups helps you to understand his/her mental model. This will help you to create a better structure and design. If you know why people group things together, you can anticipate future groupings if you need to add more choices later. Also, customers tend to organize things much more differently than the business would. It’s better to see the customer’s point of view so that you can make his/her journey successful.
What I love most about a card sorting is two things that will often surface: the surprises and the trends. Both ends of the spectrum are so wonderful when card sorting. As the administrator of the study, you want to see common themes emerge and bubble up to the surface. This helps you to organize topics cleanly and in a way the customer will enjoy. If multiple people expect things to be grouped in a certain way, that makes your life as an Information Architect easier.
The other side of the coin is items that surprises the research team. This could be especially helpful if you use a term that the participant does not understand. Most likely it’s industry or technical jargon – which should be avoided at all costs! If you do come across terms that confuse the participant in any way, consider changing or modifying it. In fact, you could ask the person what term they would use instead. Again, asking the person for feedback will often enrich your research and aide in creating a better experience.
After the study, share your insights with the team. It’s even better if members of the team are sitting in the research session with you so they can see first-hand what the participant said and did. But if you can’t have those team members who are involved in the product directly observe the card sorting session, sharing a brief, insightful report is the next best thing. The lesson here is to keep the card sorting method in your pocket for potential use in the future. Card sorting does not have to be reserved strictly for determining navigation. It’s a versatile tech-agnostic method that can be used to organize information quickly and easily. Try it out next time you need to organize and structure information.
Another good class I took as part of the Big D Conference was presented by Eva Kaniasty, the founder of Red Pill UX, and a research and design consultancy.
The role of the UX researcher is an important one. We, as UX researchers, need to design our research studies for analysis. Obviously when we perform a story, we are trying to gather important data. This data we gain in our research efforts need to be analyzed and our findings need to be communicated to others. We need to think about how to visualize our research.
Get your stakeholders to empathize with their customers and users. One way to do this is to take photos of the real people using the product. Don’t use fancy stock photography with posed fake models. Use your smartphone and take pictures of people using the product. And take more pictures of the person, sort of posed, to use as your persona image. This makes the persona more realistic and will provide the opportunity for your stakeholders to see the real person behind the persona.
I learned about the website UI Faces where you can go and get more “realistic” photos that are free to use in your personas or other needs. Granted, I checked this site out, and there’s a lot of avatars from people I follow on Twitter. But hey, your customer probably does not follow them and therefore they won’t recognize the images. So go ahead and check out the site to see if it needs your image needs for personas.
The problem with personas today is that many people just make them up. They don’t generate them using interview data or base them on real users. People often create personas based on “ideal” customers which is not accurate. Be sure that when you create personas, create them based on real research. Also make sure that they represent real people and customers, not ideal ones.
Additional notes from this talk
Pie charts are poor visualization tools much of the time.
Icons can be used to visualize data, but don’t over use them.
After you have a research session, write a quick summary right afterwards so you don’t forget the important details. The longer you wait, the more you will forget.
Videos are time consuming and become outdated quickly.
Quotes can be very powerful and easier to generate than video clips.
Look for patterns in your data.
Don’t use a word cloud to summarize data.
Word clouds are hard to read, noisy and the colors used can be confusing, portraying a confusing hierarchy.
A treemap shows the frequency of terms used in a combined bar chart.
Make any color coding meaningful and explain what it means.
Test with color blindness tools to make sure that color can be seen.
Do no over aggregate that data. That happens when you smooth and combine data together too much. When this happens, the data can lose its meaning. Don’t combine much because if you do, you can lose where the problems are.
Use words instead of illustrating with a bunch of repetitive icons.
Don’t use statistics for something subjective like severity ratings.
For “Ease of Use” ratings, use a bar chart, not a pie chart.
Stars are not good to rate the severity of something. People think more stars means “good” and that is the opposite mental model for the severity rating scale.
Dot voting is good to give everyone a chance to vote and it surfaces up the problems that need addressing first. The most votes wins!
Different people, be it a User Experience Designer or someone in the Marketing department of your company may have a persona. So what does a “persona” mean in the UX world? Wikipedia defines a person as: a fictional character created to represent the different user types that might use a site, brand, or product in a similar way. In other words, a user persona is a representation of the goals and behavior of a hypothesized group of users. In most cases, personas are synthesized from data collected from interviews with users.
How do you make a persona?
No you don’t just make it up. Pick a fictitious name, throw some random facts on a page and say “This is our personal Sally Student.” No, no, no. You use actual user research to develop a persona. As mentioned before, a person is created from combined data based on interviews and other research methods. The most important factors in a persona are generally not demographic information like age, political interests, or what type of car a person drives. Though some of these types of factors can be used to give the persona some human characteristics and personality. They key is to use information that is important to portraying the persona. They type of driving habits a person has, would not be important for a persona representing a user of medical software. But that information would be important for an app that tracks a person’s mileage and gas consumption when they drive.
Generally personas consist of:
The user’s name
Age or level of expertise
Title or some occupational reference
And perhaps a quote that summarizes the user’s goal, feeling or general outlook about the product or process
There are many advantages of using personas. Some of these include:
They simply provide a “face” for the user story.
Provide an emotional link to the person so you can build empathy with that user.
Promotes surfacing a real goal, pain points and motivations rather than just making them up as the discussion evolves.
When you need to play out a use case, the persona is a true character to use as reference, along with all of her data and behaviors.
Keeps the “facts” of the user more concrete. If it’s recorded on paper, traits of the user are less likely to morph and change.
Gives the team a focal point of on person to discuss rather than a theory about a group of users. You can specifically reference how “Sally the Student” would use the product so you make sure you are meeting her goals.
To focus the design on a “real” user rather than what we “think” is the best solution.
Now that you have a better understanding of personas, I hope that you will use them on your next project. If you are using personas now, please share your process of how you develop them and how you use them with the team.
Simply put, I love ethnographic research. I mean it when I say that this form of user research is probably the most valuable way to gain insight on your users and your product. And, unfortunately, it is far too often overlooked as time consuming or simply viewed as a waste of time. I could not disagree more!
First let’s define the term. According to Wikipedia, ethnography is:
The systematic study of people and cultures. It is designed to explore cultural phenomena where the researcher observes society from the point of view of the subject of the study.
So how does this apply to UX and research? By observing your users in their natural habitat, you get exceedingly more information and context about their real world.
The benefits of ethnographic research for me include:
You see users use your product in a natural way, not in a fabricated lab setting
It provides context to their environment
You see things that you would never discover with a phone call or what the suer just tells you
You discover that what users say they do, and what they really do can often differ greatly
You see first hand the pain points that users are not aware that they have
You can observe true behaviors
You notice the environmental factors, like interruptions from c0-workers, slowness of equipment, and other physical attributes that affect the user
You have the opportunity to ask questions, on the spot, as circumstances arise
You can record aspects of the environment by taking photographs and video that could not be done remotely
You can establish a better rapport with your users
You can observe the entire context of the working environment, across rooms, buildings, people and other circumstances
It provides impromptu “bitch sessions” that the user would probably not normally share
It allows the user to feel like he/she is being heard
It allows you to be an “eye” for the other team members who are not able to view the user’s world
It gives the UX designer the best opportunity to really empathize with the user, by seeing how their work or life really is
Hopefully my reasons have given you enough understanding and reasoning to do your own ethnographic research. If you have your stories to share about ethnographic research, please do so in the comments.
As UX designers, we have all heard our users or customers offer solutions to a problem.
“Can I have a back button at the top left?”
“Will you put these 4 item in the pull down too? I use them all of the time.”
“I’d love it if I could have a widget to help me build my plan in to a nice organized package.
“Can you put a button on the main page for me to easily access all of the uploaded files so I don’t have to click on the menu to go there?
Yes these might sound like good solutions on the surface. But it is more important to really find out what the user is having a problem with. That’s when you try to stay in the “Problem Space.”
The Problem Space is the portion of discovery where the UX designer really tries to understand the user’s problems. It’s good to hear the user out in this phase, even if he is proposing solutions to his problems. A good way to dig deeper, and to gain a better understanding of the problem is to keep asking the user “Why?” This is know as the “5 Whys” technique and is often used by UX designers to discover more information. When a user gives you an answer, ask him “Why.” And ask “Why” again. And again. This way, he will divulge more information than he might be providing to you. Get deeper in to the problem. Try to get a better understanding of what he is struggling with, what his pain points are. Maybe, when more information is revealed, you as the UX designer will come up with a better solution that the user is proposing. That is the goal anyways. Maybe you will also discover that this user’s problem persists in other areas of your site or application. And a more universal solution would not only solve this user’s problem, but many other problems too.
Albert Einstein put it perfectly when he said:
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.”
It pays off to devote more time to analyzing the problem than quickly jumping to a solution. If you jump too quickly to a solution, without really understanding the problem, you might not actually be providing the best fix for the problem.
I understand that it is easy to quickly jump to the Solution Phase. Especially if a solution, which seems like a good idea, has been proposed. But by refraining from taking the leap, which requires patience and discipline, it gives you an opportunity to really define the problem. And this is crucial to success.
Remember that residing in the Problem Phase should not express any solutions. Just focus on a complete understanding of the problem before proposing any solutions. Also, clearly defining the problem, can help eliminate ambiguous terms that might be used and to get the entire team on board with the project.
When riding home one evening in the back of an Uber car, I took advantage of a situation. Sure, I could have sit back quietly and enjoyed the ride in silence. The driver did not have the radio on, so it could have been a peaceful ride.
Instead, I decide to make the ride a bit more interesting. Don’t worry, I was not going to engage in anything illegal. I decided to engage the driver in a conversation. Gasp! Talk to a stranger in Los Angeles? What? Who does that??? Well, I do.
You see, I am a gal from the Midwest. People from that part of the world are not afraid to engage in a conversation. In fact, this art form was eloquently taught to me by my father. I can recall on several instances the following circumstance: I am in a long line for an amusement park ride. My dad is waiting for me outside the ride on a bench until I am finished. By the time I get back from the ride, my dad has had a long chat with the person sitting next to him on that bench. I didn’t even notice the person when I started to get on the ride.
So what was happening here? My dad was a very smart man, and knew that having a conversation would help pass the waiting time. He didn’t want to read a book because he liked to people watch. These were the days before smart phones. So he wold strike up a chat with a complete stranger.
Not only did a conversation like this pass the time, he also learned something. And that is what I am trying to promote here. Instead of looking down and checking your smart phone, strike up a conversation with a stranger. What was so magical about the conversations my dad would have with strangers is what he learned about the other person. He would say things like, “That guy lived just a couple of blocks down from where I grew up in New York. And our parents when to the same social hall for dances and parties.” Or he would say, “The lady I sent next to on my flight is the inventor of body glitter.”
What do you do to learn more? Just start a conversation. I know this is not easy for some people. Striking up a conversation with a complete stranger can be terrifying. But if you want to be a UX designer, you have to break out of your shell and learn how to be comfortable in a conversation with others. It’s ok, the (probably) won’t bite.
Start the conversation small, maybe make a comment about the weather or the current surroundings.
Or ask a generic question about something you “seem like” you need assistance with like the time the the store is closing or do they if know….
Maybe you can make a comment out the phone they are looking at. Ask, “Oh is that the new iPhone? Do you like it?” People love to talk about their gadgets.
Gage the person’s reaction, if they give you a short answer, they might not want to chat. See how negative they seem.
If they ask you a question back, it’s a good sign they might want to have a conversation.
If a person is reading a book or has earphones on, this is a sign they might not want to talk to you. But if they are just gazing at their phone, they are probably just killing time.
Don’t get too personal. But it’s ok to ask what they do for a living and what they do in that type of job.
Just remember that people love talking about themselves, and the point of this exercise is to learn, so let the person do a majority of the talking.
Be brave, learn to read others and be safe.
But most importantly have fun and embrace the opportunity to learn from every experience.
When conducting user research, there are a variety of methods to acquire valuable data. This chart, courtesy of the Nielson Norman Group, illustrates the ranges that your research can measure.
Let’s break this down to the extreme ranges of this chart.
Ethnographic research is a fine example of behavioral research. This is where the researcher goes in to the user’s natural environment and observes the user in the user’s normal and regular context.
Surveys and Interviews are some ways to see what the user says they would or would not do something. Often users will give answers they think the research wants to hear or what they think is the “correct” answer. The key here is that the user might actually believe what they are saying is true. But in fact, when the researcher actually observes the behavior, what the user has said might not be accurate.
One-on-one interviews and ethnographic research are a couple of great ways to get qualitative research information. The researcher can devote individual time to the user, and really get deep information about them. This takes time, and therefore can be difficult to accomplish in mass quantities. But submersing yourself in the users world will provide much more in-depth information than more quantitative research methods.
Surveys accomplish quantitative research very well. Especially with the plethora of online survey tools (many of them are free), one can easily send out a survey to hundreds, if not thousands of participants and gather a large amount of data. This data can then be accumulated to show trends, make charts and post results of several people. However, this research method does not provide individual insight and appreciation that a more qualitative research will provide.
All in all, there are many research methods that a UX researcher has at his or her disposal. They key is to know which research method is best for the type of information he or she is seeking. Also, many of research methods fall within the middle ranges of this chart, and not at the extremes. I encourage you to use a variety of research methods in your next UX project.
Travel sheets are a traditional medical document used by doctors as a sort of a check list of conditions. It’s a quick way to mark items that a patient may or may not have.
What do I know about medical exam travel sheets? Absolutely nothing! But that is a great start for any UX Designer. You don’t have to be an expert on your subject so start researching. In fact, the less you know can work to your advantage. Approaching a topic from a completely new and innocent perspective allows you to empathize how someone else who is new to the subject will be introduced. You have fresh eyes, less bias and a lack of knowledge to jump ahead of yourself.
So if you don’t know a lot about a topic then get started on learning. Use the web to research what others have said on the same topic. I don’t have to tell you the wealth of resources there are online. Also, talk to your stakeholders and clients to learn from they. they know their subject, and they should not be afraid to share this valuable information with you.
There are many people trying to figure out how to make the jump in to the UX field. I too, not too long ago, was trying to transition (or to use the buzz word “pivot”) in to the field of UX. Thankfully, I made the transition and I am now a UI Designer. However, it took a lot of hard work, networking, self discipline, education and pushing myself to learn more about UX every day.
One way I went about getting experience about UX was to learn as much as I could about the deliverables in the UX field. I would hear a term like “personas” or “wireframes” and decide that I was not only going to learn as much as I could about these topics, but I was also going to put it in to practice.
Here’s an example. Say you are a web designer for a flower shop. Sure, you could just design the website per the shop owner’s request. But why not take it a step further? Why not do a bit of discovery and research before starting the design project? You could interview the owners and customers to find out what the business goals and customer goals are. You could do a bit of ethnographic research by observing people shopping for flowers or employees performing a transaction. Sketch our a few concepts before diving in to the code.
If you are trying to get experience in UX, and want to build up your portfolio, use some or many of these methods to show that you are so much more than a visual designer or developer. Show off your analytical skills and how they are applicable to a career in UX.
Here is a brief list of UX deliverables to get you started:
Information Architecture (Taxonomy)
Examine Business Goals
Examine Customer Goals
Site Map and Architecture
Whiteboard and Sticky Notes
Use Case Scenario
Persona Empathy Map
Cognitive Walk Through
Now take all of these deliverables and practice creating them. Then, use the most important UX skill of all: Tell us Your Story.
One way to really understand how your users work on your product is to view them in their natural environment. That puts their working circumstances and environment in perspective. By observing people, you see things they would not normally tell you. Maybe because it’s so routine they don’t realize they are performing such actions. Maybe because they do not think it is relevant. If you just observe a person in their work situation, then you can decide what actions they take are related to the software or product you are working on.
Here are some questions to keep in when when you are performing an ethnographic research study:
Is the work place quiet and calm?
Do the users get interrupted a lot?
What other tasks do they do while working on your software or product?
How is the work station set up? Is it on a desk? A counter? Shared by several users?
What real world objects do they use instead of using the computer? (like post-it notes and pens)
You can learn a lot by acting as a “fly on the wall” and getting a feel for how the workplace is run and how the software interacts in that work flow.
Value of Ethnographic Research
I cannot express enough how important it is to get out of the office and get in to the user’s real world. In the photo above, had I not visited this doctor in her office, I doubt she would have told me about her paper files organization. It’s just as useful to understand a person’s physical environment as it is to understand their electronic or software environment. That way, you can figure out how you can make the two world meet seamlessly.
Plus, you get to see things like these cutie pies.
I find that the best best place for me to start on a new project is to see what’s already out there in the world. I like to do a bit of research, and see what items exist that are similar in design and purpose. It helps me to think about possibilities, what I like and what I don’t like.
I am currently in the process of designing a Dashboard that will be used in several veterinary hospitals. Having never designed a dashboard before, I thought I would scour the internet to see what visual examples I could use as inspiration on helping me get started.
After viewing various dashboard examples, I figure out what traits apply to my design concept, and what do not. Even though I might not have a pie chart in my concept does not mean I would discard a design completely. It’s often useful to pull pieces from several designs and combine them in to one.
As you can see from the collage of Dashboards above, they have a variety of components. Some work within my design and some do not. As the project progresses, we will see if any of these designs or pieces of the design end up in the final product.
Here’s a short description of the user research methods shown in the above chart:
Usability-Lab Studies: participants are brought into a lab, one-on-one with a researcher, and given a set of scenarios that lead to tasks and usage of specific interest within a product or service.
Ethnographic Field Studies: researchers meet with and study participants in their natural environment, where they would most likely encounter the product or service in question.
Participatory Design: participants are given design elements or creative materials in order to construct their ideal experience in a concrete way that expresses what matters to them most and why.
Focus Groups: groups of 3-12 participants are lead through a discussion about a set of topics, giving verbal and written feedback through discussion and exercises.
Interviews: a researcher meets with participants one-on-one to discuss in depth what the participant thinks about the topic in question.
Eyetracking: an eyetracking device is configured to precisely measure where participants look as they perform tasks or interact naturally with websites, applications, physical products, or environments.
Usability Benchmarking: tightly scripted usability studies are performed with several participants, using precise and predetermined measures of performance.
Unmoderated Remote Panel Studies: a panel of trained participants who have video recording and data collection software installed on their own personal devices uses a website or product while thinking aloud, having their experience recorded for immediate playback and analysis by the researcher or company.
Concept Testing: a researcher shares an approximation of a product or service that captures the key essence (the value proposition) of a new concept or product in order to determine if it meets the needs of the target audience; it can be done one-on-one or with larger numbers of participants, and either in person or online.
Diary/Camera Studies: participants are given a mechanism (diary or camera) to record and describe aspects of their lives that are relevant to a product or service, or simply core to the target audience; diary studies are typically longitudinal and can only be done for data that is easily recorded by participants.
Customer Feedback: open-ended and/or close-ended information provided by a self-selected sample of users, often through a feedback link, button, form, or email.
Desirability Studies: participants are offered different visual-design alternatives and are expected to associate each alternative with a set of attributes selected from a closed list; these studies can be both qualitative and quantitative.
Clickstream Analysis: analyzing the record of screens or pages that users clicks on and sees, as they use a site or software product; it requires the site to be instrumented properly or the application to have telemetry data collection enabled.
A/B Testing (also known as “multivariate testing,” “live testing,” or “bucket testing”): a method of scientifically testing different designs on a site by randomly assigning groups of users to interact with each of the different designs and measuring the effect of these assignments on user behavior.
Unmoderated UX Studies: a quantitative or qualitative and automated method that uses a specialized research tool to captures participant behaviors (through software installed on participant computers/browsers) and attitudes (through embedded survey questions), usually by giving participants goals or scenarios to accomplish with a site or prototype.
True-Intent Studies: a method that asks random site visitors what their goal or intention is upon entering the site, measures their subsequent behavior, and asks whether they were successful in achieving their goal upon exiting the site.
Intercept Surveys: a survey that is triggered during the use of a site or application.
Email Surveys: a survey in which participants are recruited from an email message.
First thing I wanted to do before tackling the Hollywood Walking Tour App was to observe how tourists do research or way find on the boulevard. I wanted to see how people navigated the area. As suspected, some tourists were holding up unfolded maps or looking at books. Some people were part of a larger tour group, being lead around by a hired guide. Some were standing to the side looking at a smart phone. Perhaps they were researching the area? And others were just wondering down the street checking out all of the starts on the sidewalk along the way.
As part of discovery for my Hollywood Walking Tour App, I thought it would be a good idea to compare other apps that are available on the market. Granted, I only looked at free apps. But I want my app to be free, so this really is my competition. I was really shocked and surprised how poor the apps were for apps concerning walking tours in Los Angeles, and specifically Hollywood. The Hollywood walk of fame is surely bar far one of the biggest tourist destinations in Los Angeles. And it is best seen of foot. So I was really disappointed in the apps on the market now covering this topic.
Below I am comparing several apps that either have to do with Los Angeles tours, walking tours, or a combination of both.
For the Hollywood Walking Tour app I am now developing, I thought it would be a great idea to go to one of Hollywood’s biggest tourist traps, I mean spots. I spent a couple of hours observing tourists and talking to them about their traveling experience. Specifically, I wanted to see how people navigated the streets (Did they use a map or guide book? Or were they just wandering aimlessly?) and find out how they researched their trip to Hollywood. Here are some observations I made:
I recently took it upon myself to compare three online movie ticket purchasing websites: Fandango*, movietickets.com and Arclight Cinemas. By comparing the features, design, content and user flow of similar websites, one can gain invaluable knowledge about their own sites.
When you compare your website to what a competitive website is doing, you will learn:
What your website or experience is doing right
What your website or experience is doing wrong
What your competitors are doing right
What your competitors are doing wrong
This is a great jumping off point in improving your own website or experience.
This graphic only shows some some of the insights I discovered when comparing websites. My brief overview is below:
* At the time of publishing this post, Fandango had not yet released its redesigned website and mobile app. Therefore many of the specific features I discuss here will no longer be applicable. However, going this process was still a great learning tool.
I know that Fandango will be launching a redesign very soon, so the shelf life of my analysis is ver limited. Still, I would like to share with you a few things I learned when analyzing Fandango.com website on the desktop:
If something looks like a button, then it should be a button. The “Find Movie Times + Buy Tickets” looks like a button, but is not. Best not to confuse the user.
Movie posters can be too small and sometimes difficult to read the title. Maybe use a simpler image to illustrate film? And therefore help me read the title of the film.