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.
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.
My role is Researcher, Team Lead, Guide, Mentor
User Research – Generative – Contextual Analysis, Interviews, Evaluative – Heuristic Analysis, Expert Evaluation/Walkthrough, Persona building, scenarios, empathy
2. 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!)
3. Feasibility Checks: My role is Scrum Master, protector of teammates.
4. Wireframes and Prototypes: My role is vision/gatekeeper, facilitator, Product Manager
5. Orchestration and Collaboration:
I unravel things, focus them, and create positive change.
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!
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.
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.
*First shown on medium.com
DESIGNERS SOLVE PROBLEMS
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!
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.
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.
If 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.
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.
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.
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.
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.