UX Unicorns

This blog post is adapted from a presentation I gave for a design manager role, so it is more focused on me than I would like. The mythical UX unicorn doesn’t seem to be going away and I haven’t truly decided if I’m further in the camp of “most of us are unicorns” or “unicorns don’t exist”. For this role, I was directly asked “what makes you a unicorn?”, so I ran with the first perspective. Enjoy.

What makes a unicorn??? There are two definitions of a unicorn – 1) The greatest thing since sliced bread…which I am not. 2) A creature that combines specialties in a unique and effective way.

In the case of an actual unicorn – it has the strong body of a horse, the strange horn of a Narwhal on land, and it may or may not have magical powers and a rainbow mane.

For me, my strong body is made up of UX Research methods and techniques. I am always passionate and empathetic to the experience of the end user and I know how to get teams on board with that.

Screen Shot 2018-06-18 at 9.07.02 PM

As a Product Owner and Product Manager, I’ve been a bit of a Narwhal on land! I’m knowledgeable and respectful of Agile processes and often reference myself as a “dev groupie”. 

My magical powers and rainbow mane come from my background as a Data Curator. Depending on the topic, data curation allowed me to be really technical or very creative and out of the box – but always passionate about making data and content usable and FINDABLE. Believe it or not, datasets can go viral – find it, use it, love it, tell everyone about it. I spent years working with data and data systems to ensure that people can find what they need and easily use what they find.

Screen Shot 2018-06-18 at 9.10.07 PM

  1. Information Gathering/Problem Definition: 1219-512

My role is Researcher, Team Lead, Guide, Mentor

User Research – Generative – Contextual Analysis, Interviews, Evaluative – Heuristic Analysis, Expert Evaluation/Walkthrough, Persona building, scenarios, empathy

cropped-Living-Synergy-Icon-lge2. Participatory design (originally co-operative design, now often co-design) is an approach to design attempting to actively involve all stakeholders (e.g. employees, partners, customers, citizens, end users) in the design process to help ensure the result meets their needs and is usable.My role is facilitator, researcher presenting findings, creativity encourager (not exactly cattle prod!)

  • What problem(s) are we really trying to solve?
  • Cross-department Design Workshops
  • Brainstorming
  • Rapid Prototyping
  • All stakeholders involved and heard – building buy-in!
  • Level of Effort and Value

Screen Shot 2018-06-18 at 9.15.53 PM3. Feasibility Checks: My role is Scrum Master, protector of teammates.

  • Constraint breeds the next level of creativityplanning-feasibility-300x300
  • Devs, designers, data peeps
    • Roadblocks?
    • Opportunities?
  • Deep Dive into Level of Effort
  • What do our Participatory Designs actually mean for the system?
  • Reassess LOE and Value
  • Legacy system negotiation
  • Understanding tech debt


vector_design_icon_bezier_curve_draw_sketch_drawing-1284. Wireframes and Prototypes: My role is vision/gatekeeper, facilitator, Product Manager

  • Intrinsic/extrinsic = white hat/black hat motivators
  • Gamification
  • BJ Fogg’s behavior model – Trigger, motivation, ability
  • More of the traditional design process happens there
  • Iterate with screens and workflows
  • Lo-Fi and Hi-Fi wireframes and prototypes
  • Information Architecture research
  • Card Sorting, task analysis
  • Menus, navigation
  • Get the wireframes in front of users!
  • Iterate with screens and workflows
  • Compare findings to our original research and problem statement(s)
    • New scenarios?
    • ADA?

5. Orchestration and Collaboration:collaboration

  • My role is Product Owner, ~Project Manager
  • Conductor
  • Ensure buy-in and shared vision throughout the process
  • Stories and agile process w/ devs
  • Manage product briefs
  • All info in one place and up to date for everyone!
  • Collaboration with Marketing, Data, DevOps, Resident Life, etc


Tell Me About Yourself…

Executive Summary

I unravel things, focus them, and create positive change.


The Longer Version

When I was a kid, I wanted to be a teacher. Ok, I also wanted to be a rock star, but that was a phase, I swear!  I’ve always been passionate about people, science, art, and business. In college, photography was the penultimate combination of art and science…and running a photography business settled the craving for autonomy and learning about people.

But after 10 years, something was missing. I’d interview couples about their wedding plans, but I wasn’t in a role to ask them deeper questions about who they are and what they wanted in life or why they made different decisions. I started to feel that making pretty pictures wasn’t important enough.

In 2007 I went back to school and took every psychology and physical science class I could get my hands on. My business stayed strong on current clients and referrals. I felt so fortunate to have the luxury to do this! I was searching for the combination of challenging work and a higher purpose than basic profit.  I wanted to do research!

But, in academia, there are sides. You must choose between the physical and the social sciences. I hated that. To me, they inform each other just like qualitative and quantitative research. I finally found an organization that did interdisciplinary science with the goal of improving weather communication (warnings and education) in order to save lives. It was perfect and I dove in deep!

My Master’s thesis was an evaluation of the TsunamiReady program. TsunamiReady is an educational program led by the National Oceanic and Atmospheric Administration (NOAA) that helps local communities prepare and educate residents and visitors about tsunami events.

Much of the communication from cities to residents was through road and traffic signage. I was traveling and giving talks about my research. People wanted me to share my data, my findings, and my stories. I didn’t know it at the time, but my thesis was a UX research project!

I didn’t know it at the time, but my master’s thesis on tsunami warning traffic signs was a UX research project!

Careers in science are difficult. A career in interdisciplinary science is even more difficult! I was fortunate to get the choice between doing a PhD or diving into work. I chose to work for several reasons – my friends with PhDs were struggling, the job was more interdisciplinary than the PhD program, and I like getting my hands dirty. I really wanted to roll up my sleeves and make things happen! And, let’s face it, the immediate reward ($) was better than the high anxiety of semester by semester funding.

My UX life “officially” began at the National Snow and Ice Data Center (NSIDC) at the University of Colorado Boulder. I did all of the usability research for the ACADIS project and for the Arctic Data Explorer (ADE). Later, I also became the Product Owner for the ADE.

No matter how smart you are, physical sciences love their ivory towers. Without the PhD, I felt dismissed no matter how loud I shouted. Armed with knowledge of Big Data, data analysis, data management, UX Research methodologies, and a history in business, I left academia for industry.

So, why do I love UX research so much? And what can I do for your company?


UX Research is very much an interdisciplinary science. That means that each member of a team invariably will have different meanings for the same words. Clarity and the willingness to ask are hugely important. When various components are moving in different directions, change is either impossible or chaotic. Positive change requires a concerted, team effort and tons of tenacity. Interdisciplinary science is all about “moving the barge.” I have the ability to be a PITA and still have people like me.

Business is greater than the sum of its parts. And profits are sweeter when they actually help someone. All too often, organizations lose sight of why they exist – to help customers. They lose sight of who the customers are or how those customers change. It’s all too easy for businesses to fall apart or go astray. The way I see it, it is my job to make sure the organization knows exactly who they are serving, how they are helping, and WHY their solution works.

Designer or Cook?

*First shown on medium.com


For the longest time, I felt like I didn’t deserve the title of “Designer.” I’ve been a UX Researcher for almost a decade. I’ve had the title of Product Owner and Product Manager and even Founder of my photography company. As that Founder, I created my company’s websites either by my own hand or working with a small dev team. I constructed photo collages and beautiful wall-sized prints. I designed wedding albums and baby picture books. Yes, I “designed” albums…but I never felt like a “Designer.” And I didn’t know why…until now.

A few days ago I was a a panel meetup and asked our esteemed guests this question:

“I have an analogy for you. I’m a foodie and love watching cooking shows. In that world, there is a big difference between being a cook and being a Chef. It’s more than going to culinary school or even owning your own restaurant. In tech, what do you see is the difference between being a crafter or hobbyist and being a Designer? What does it take to cross over?”

The panel was silent.

The man from Google eventually piped up and said “You just have to give a shit.” Then they were silent again.

As a photographer I could explain the difference between a professional and non-professional photographer was. Part of it was just getting paid for your work. Another part of it was your level of dedication to the craft and to sales. To this extent, “giving a shit” made some sense, but it was entirely unsatisfying.

As the silence built, I had a moment of terror. I had put myself out there and was met with blank stares. “Shit — here we go again,” I thought. But I’ll save the imposter syndrome talk for a different post.

Another panelist, Jules, finally said “As the only non-cis male on this panel, I’d like to add something.”

RELIEF! I’m going to learn something after all!

Jules dropped the wisdom that if I’m so afraid to call myself a designer, then there must be something deeper to it and that I should explore further. He told the audience that design is more than the visual by recounting his own worries about creating pixel perfect images. We were all beautifully reminded that to be a designer means that we solve problems.

Thank goodness for some diversity on panels! The other panelists were now able to echo the ideas that Jules contributed and give some more detail. In the end, the Google guy said he’s going to use my Chef analogy on his teams! Proud moment to feel so Googlie. 🙂

I’ve been defining and solving problems for a long time. Through those job titles I mentioned, though mentoring startup teams, and by being a friend who genuinely gives a shit.

So what’s the bottom line? Recognizing that I assumed being a Designer was just the visual design part and seeing that I was afraid to put down the shield of my quantitative side, I can see why it was so impossible to call myself a Designer. But here I am, World — Problem Solver, Designer. Let’s go!



Onboarding Qualitative Research

Charter Communications Business Enterprise team was courting me for months. It was an excellent match, but it came down to location. The following was presented to them as the research plan for how to integrate me as a qualitative researcher for their business clients.


Operationalization and Delight

Love is really hard to define. So how do you define what to build when your goal is to make products that people love?

I did a little exercise to try to define that Limbic system “feeling” and put it into words. I chose a product that I use every day and love as well as a product I use every day and DON’T love. The key was to look at attributes of each in terms of tangible and intangible and what is good and what sucks.


What I found out is this is a great exercise for persona work. Perhaps your company provides a product that is a necessary evil (Comcast anyone?). If so, your customers use you every day, but you have a different bar to delight them than most of the blog posts and business journals give advice for! It’s important to know what about your product and what about the people keep you afloat.

masteryIf it is an interface, let’s compare it to our customer’s interface. Here is an example with basic heuristic attributes on a radar/spider diagram. Be careful where you place attributes on a radar diagram since the area covered can easily be manipulated!


And it doesn’t have to stop there. Let’s compare delight over time with the level of money/effort that the company puts into their product.


Senior-level Job Interview

I was really excited at the potential to work with a Collective Intelligence SaaS software company. The challenge behind the product was to build engagement and participation through psychological safety and global collaboration.

As the Senior UX Researcher at the company, I would be responsible for building the research program. It was no surprize that the “design test” was to build and explain a research program for a fake app.


Given this minimal information, certain items stood out in the data. There are goals set in this budget, but I do not know how or why they were set. What is the purpose of this software and why did the user select this program? Did she create the categories? If not, did the data get parsed properly?

I started writing all these questions, issues, and ideas on sticky notes. After a while, I saw some patterns emerging so I moved to affinity mapping them into the clusters.

Affinity Mapping to organize ideas

To really build upon the questions, I imagined which methods and tools would be most appropriate to answer those questions. From there, it was nearly straightforward to decide on potential company KPIs and regular deliverables based on those tools. I included those in their own swimlanes and color coded stickies.

What it looked like when I presented 45 min later
Screen Shot 2017-08-15 at 2.38.29 PM
What those stickies actually say!

I called the guys back in and we spent some time going over my ideas. They questioned and “ooh’d and aah’d” before we decided to get happy hour downstairs.

It was one of the best teams I’ve ever worked on and I miss them.


UX Tenets and Traps

Since May 2016, I’ve been working with Michael Medlock and Stephen Herbst from Microsoft and Honeywell to develop the UX Tenets and Traps book, website, and card deck.

After watching this amazing video, I was moved to contact them and see if I could get involved! Turns out, I was just the kick-in-the-pants they needed to get the ball rolling again.

Our solution is for UX, product, design, and engineering teams. The method distills 100 years worth of user interface research so that teams can quickly identify problem areas.


Check it out! www.uitraps.com


TENETS describe attributes of good UI design. TRAPS describe common, detectable problems that degrade good design. Eliminate traps and the customer experience improves!


More than 100 years of research on human perception, cognition, memory, and ergonomics synthesized into an accessible and actionable deck of cards that teams can use to detect and resolve potentially costly UI problems early in development.


Developed and applied at Microsoft where it won the 2013 Microsoft Engineering Excellence Award. Now available to the public for the first time.

uitrapsWatch the featured talk at the 2014 Microsoft Build conference


tenets traps contributors





Educational Background

The summary is that each of our lives are constantly evolving which means our communication can constantly improve. My philosophy is…  Let’s investigate so we can go in the right direction. And then…  Let’s look back and measure a bit so we can celebrate the hell out of our wins, big and small.

University Classes:
  • Social Psychology
  • Cognitive Psychology
  • Developmental Psychology
  • Personality Psychology
  • Research Methods in Sociology
  • Public Speaking
  • Interpersonal Communication
  • Environmental Policy (debate)
  • Women’s Studies Research/Practicum
  • Library Research
  • Graphic Design
  • Computer Graphics (Adobe CS)
  • Art History
  • Drawing
  • Tons of photography and lighting classes!
  • Software Project Management
  • Economics and other business courses
  • *many* Statistics classes – in anthropology, math, philosophy, engineering, geography
  • etc.
And for a lifelong learner like me, there’s always less formal education like:
  • Agile Coaching workshop (Eliassen)
  • Tons of marketing seminars (UCLA, etc.)
  • Programming/Dev and Data Science meetups, workshops, and conferences
  • Agile methodologies meetups, workshops, and conferences
  • Creating my own direct mail marketing campaigns and seeing ROI
  • Iterating on product order forms and seeing thousands of people use them
And volunteer experience like:
  • UX mentoring for Go Code Colorado
  • Usability research reviews for friends and co-workers
  • Research Assistant in the University of Colorado Boulder Social Psychology JEDI Lab (Judgement, Emotion, Decision, Intuition Lab)
  • Editing and rewriting lots of copy/content (websites, science proposals, advertising, love letters, angry emails)
  • Listening (and genuinely helping) friends, acquaintances, and Meetup attendees.

Sharing Research Data

Reposted from Inna Kouper’s blog


Toni Rosati is a data curator and a usability researcher at the National Snow and Ice Data Center (NSIDC). Toni is involved in several projects at NSIDC, including the Advanced Cooperative Arctic Data and Information Service (ACADIS ) and the Science-Driven Cyberinfrastructure: Integrating Permafrost Data, Services, and Research Applications (PermaData).

Toni and I met at the 5th Research Data Alliance plenary and sat down during one of the coffee breaks to talk about qualitative data and the challenges of sharing them. As a usability researcher and a member of the ACADIS team, Toni conducts tests of the Arctic Data Explorer (ADE), a federated search tool for interdisciplinary Arctic science data. Her research results in recommendations to ADE managers and software developers to improve appearance, functionality, and quality of search results of the tool. Diving deep into the metadata and the code that make the ADE possible, Toni is also, ultimately, looking to improve data management and data sharing practices.

The usability tests generate a wealth of qualitative data including interview recordings and written transcripts. But, can the raw be shared? Not at this point, says Toni, for the following reasons:

  • Toni has been working closely with their institutional review board (IRB), an ethical committee that reviews and approves research involving humans in the U.S. to come to this conclusion. To ensure privacy, raw identifiable data must be anonymized.
  • The raw data are collected in the context of an organization and are most valuable for the organization itself rather than for an outside scholarly community; however, the methods and results are extremely valuable to the outside community and will be shared.

Does anything need to or can be shared in this situation?

In short, yes. As Toni pointed out, the most valuable sharing of qualitative data in an organizational context is the sharing of data that has undergone expert interpretation. “I’m collecting a lot of qualitative data, but to be most useful to my teammates, they have to be distilled into quick actionable items,” says Toni. Qualitative data are sometimes hard to communicate, and building trust in its validity requires time.

Toni and ADE Principal Investigator Lynn Yarmey are writing a paper outlining the user experience / usability research methods and processes they undertook, and the results and lessons learned. Ultimately, usability research is intended to create software with an end user focus that is intuitive, complete, and pleasurable to use. Ms. Rosati is passionate about such research and welcomes your questions.

Search Pathways

Wayfinding can be defined as the characteristics by which someone finds their way around. The word is usually used in a physical context like in a city or building. It can also be used to describe how people give directions in physical space (i.e. research says that women tend to use more land markers whereas men give more cardinal directions).

My research team and I decided to use this concept when testing our online data search tools (Arctic Data Explorer and NSIDC Search). Our audiences have similar characteristics, but Arctic Data Explorer users tended to be more general searchers whereas NSIDC Search users sought out very specific data sets.

Rather than base our hypothesis on gender, we suspected that a user’s level of experience in the science world influenced how they searched for data sets. It turns out we were partially right. It isn’t necessarily how long the user has been in science, but how familiar they are with that particular branch of science.

userssearchpathwaysBoth of these search tools share underlying technology and have the same goal – get users to the data they want! But, given the slight difference in audiences, some interface adjustments were required. The easiest thing to notice is that NSIDC Search has lots of very specific facets to help users drill down whereas the Arctic Data Explorer allows users to do a freeform text search. But what other differences do you see?

28 Days Later


Our assignment for  CSCI 5839, User Centered Design at the University of Colorado Boulder, was to work with a team to design a mobile app using UX research techniques.


Mia Fuhrman  (msfuhrman @ gmail.com)
Skatje Myers  (skatje.myers @ colorado.edu)
Janeen Neri  (jane0320 @ colorado.edu)
Toni Rosati (uxtoni @ gmail.com)

Process, Research Design

  1. Ethnographic research about how mobile devices are used in public.
  2. Pitch an app idea that is interesting and has a viable market
  3. Draw Comics of users interacting with the app in various scenarios
  4. Survey and Cultural Probe research about our app idea
  5. Develop prototype personas and conduct a competitive analysis
  6. Create 3-4 initial designs (drawings, sketches)
  7. In class user testing
  8. Select 2 designs to develop further for testing (digital mockups)
  9. Moderated user testing (in person interviews)
  10. Select one design for further testing using an “animated” paper prototype
  11. Moderated user testing (in person interviews)
  12. Iterate on the design and create a working Axure prototype
  13. Moderated user testing (in person interviews)
  14. Storyboard for a pitch video

Key Findings

There are many period tracking apps out there. They all glamorize “that time of the month” with user interfaces involving bubbles, flowers, and lots of pink. Unfortunately, most women do not delight in “Aunt Flo’s” monthly visit.

Only 25% of survey respondents took note (mentally, physically, or digitally) of when she will be ovulating. Yet, every respondent reported at least one menstrual/PMS symptom within the last 90 days.71% of the 48 survey respondents are using some sort of tracker app. 84% of respondents who use a tracker app are able to log data in less than one minute. We decided to move forward with the idea and focus on biological females who are not trying to conceive.

One surprising benefit of using a cultural probe was the sheer range of responses it encouraged. It paired very well with the strict, easily quantifiable results of the survey. No two people chose the same three symptoms, and the symptoms weren’t straight off the Wikipedia page for “menstruation”.

Visual communication and cues are needed alongside text labels. People were more confident in making a selection when they were quickly able to confirm their assumptions with multiple cues.

Results from the Cultural Probe qualitative research study
Comic of how and when a user might open the app
My initial design
My early digital design

Analyze Boulder

Analyze Boulder is a community of data geeks who live, work, and play in Boulder, Colorado. Our members give fast, accessible, high-energy TED-style talks once a month on any data topic.  I’ve been on the leadership team since 2014. I’ve been the Emcee since 2015. Come see us anytime!



Analyze Boulder was founded because, all too often, data science communities are built around particular technologies. With technologies being so ephemeral, groups would start and quickly die before giving real benefit to members.


Analyze Boulder is a tool-agnostic community of data and analysis lovers. Presentations can use any technology, but can never be about pitching a company or selling a solution. We dive into the methodology and data analysis choices instead.



  • Analyze Boulder began in May 2013 and meets once a month.
  • We are 2,000 members strong!
  • We have participated in Boulder Startup Week for 4 years.
  • The State of Colorado provided us a generous grant to aid our operations.
  • We quickly grew out of Avery, Scribd, and other spaces. Galvanize Boulder has been our home for over 2 years.
  • After many requests, presentations are now broadcasted live via WebEx and archived on our YouTube channel.