UXPA2019: Ambiguous UX Skills and using them to advance your career and the profession

Editor's Notes

• #3: Hello! My name is Carol Righi, and I was graciously invited to speak today by the good folks at the UXPA. I am currently the Human-Centered Design Practice Lead at a software development company in St. Louis called1904 labs Right now, in the spirit of Steven Covey and the Seven Habits of Highly-Effective People, I’d like us to begin with the end in mind, and talk about what we’re going to talk about. My goal today is to share some musings about this topic of Ambiguous UX. The presentation is as a way for us to think about and talk about ways we can do three things
• #7: First, I’d like to get an idea of who you are. - Please raise your hand if you: - work as a UX professional within an organization creating tools and experiences for that organization…it can be industry, education, for profit, not for profit - work in a consulting organization, or are a freelance consultant - do UX full time - UX is one of the things you do – you may be a BA, or a PM… - are primarily co-located with other UX professionals - are primarily co-located with a development team - are all by yourself - work on one project at a time - work on multiple projects
• #8: So, who am I and why am I here today? Background in psychology, cognitive psych, emphasis in grad school was technology applications to education. Timing was good because there seemed to be a desire to bring understanding of humans to the development of technology 1992 started my career in this field whose name has changed periodically…I started as a usability practitioner at IBM. We were a big team of folks who primarily researched how well a product that someone else designed -- most of the time, software developers -- was performing with users. About this time, pockets of folks at UCD folks at IBM began to advocate for not just testing and fixing designs, but to drive the design from the getgo. Many of our colleagues, mostly in Silicon Valley, were driving to be more involved upstream in the software development lifecycle. We began to distinguish different skill sets within Usability; I became manager of the Usability Research team for the OS/2 Operating System and its extensions, sitting alongside of a design team. Success! 1994 was also special to me as it was my first UPA conference. UPA was a baby in its 4th year of existence. My recollection of that conference was a ton of energy and optimism, tinged with a wistfulness that, If they only let us do more design! Products would be so so much better! In 1995, I took a position within IBM that allowed me to work from home. My background in Ed Psych landed me in the Corporate Training division of IBM, where I developed courses and taugh developers, designers, project managers, and others, How to do User-Centered Design – a more fulsome process that engaged both research and design, working in tandem with development, to create products, I got to run around IBM talking to practitioners, researching what competitor companies were doing under the auspices of UCD, and in the spirit of staying just one step ahead of your students, taught classes in UCD. In fact, two of the people I worked with wound up wriiting a book about this...featured in the process we were developing at the time was the concept of designing all aspects of what the user sees, hears, and touches – something we called the “Total User Experience.” In fact, this may have been one of the first times the term “User Experience” was used in the literature. In 1998, with the birth of my first kiddo who turned 21 on Sunday I left IBM and struck out on my own as an independent consultant, and did that for all but 3 of the following almost 20 years. As a consultant, I did primarily research, but also design and information architecture. I broke up that time with a three-year stint as a director of a UCD consulting team housed in a software development consulting company. Today I am again Director of a team, also in a software development company.
• #9: In your job, tod
• #12: I’m sure most of you have seen what are called “ambiguous figures”
• #13: Here’s another one
• #14: Language can be ambiguous. It can lead to having a chuckle…
• #15: …or in the case of the expression “throw mama from the train a kiss” it can lead to tragedy.
• #16: The arts have brought us ambiguous stars like David Bowie and
• #17: Lady Gage
• #18: Ambiguity can be extremely helpful
• #19: Today, I’d like to take a broad interpretation of something having two meanings. So in this slant of the meaning of “Ambiguous” I’d like to take some common skills we all use day to day, and look beyond the typical meaning of each, and stretch them to examine how we can use them to advance our careers, and help move the profession forward. ENHANCE our roles ENRICH our organizations ADVANCE the profession
• #23: What are some of the benefits of contextualizing your findings? - You are teaching - You gain credibility and trust - You keep yourself honest…it’s almost like a self-audit. It forces you to ask, Is this really an issue? If so, why?
• #24: Here’s another example. Now, when I show this on the right, a lot of folks have a similar reaction: That’s a lot of words. People don’t read, and it looks dense and uninteresting. That is a totally valid point. What could you do to ensure the information on the right is used as intended? - Deliver it in person – present this, make it a dialog, explain. - Put the long chunks of text in speaker note
• #28: This is a typical journey map for a persona
• #29: Bottom line is that visualizations are a powerful tool, and that we should think about using them more broadly than we typically
• #31: Part of what we do when we engage in product design or development, we want to understand the goals of the business stakeholders by consuming what they already know, what they tell us, what research they’ve done, etc. We can however enhance our value by not only listening to our stakeholders, but by helping to shape their understanding. One way to do so is to give the stakeholders advice about the broader industry.
• #32: Part of what we do when we engage in product design or development, we want to understand the goals of the business stakeholders by consuming what they already know, what they tell us, what research they’ve done, etc. We can however enhance our value by not only listening to our stakeholders, but by helping to shape their understanding. One way to do so is to give the stakeholders advice about the broader industry.
• #33: A few years ago, I worked on a project to help a consulting company that did large scale data migrations. They had a very loose process, it was ad hoc, it really depended on the specific people who worked for them to know what to do. The person who brought me in believed the company needed a better way to manage the process by creating a tool. So, I did two things to help the company understand why they should invest in to creating this tool.
• #34: First was to bring to them
• #35: In addition to sharing industry trends and best practices, we also want to share what we know about process, which I referenced in the last example...that is, why having a defined process in place makes a difference with regard to results. That we can’t treat every design challenge as something that dropped out of the sky without having a basis for how to approach it. It may sound like process makes you weak: That it would be better to somehow represent that you have a special skill no-one else has. If your goal is to promote yourself as an individual contributor – if you are trying to say you have special skills, then saying you succeed because of process, then it sounds like you’re not special – that you’re just using a cookbook. With that reasoning, anyone can do what you do – just open the cookbook, and follow the recipe. But that is a false choice. It’s not that you’re Don Draper or a hack. Process doesn’t make you weak. A process is not a cookbook that anyone can simply follow. It’s a set of guiding principles. An experienced practitioner knows how to apply those principles, how to modify them as needed, when they do and don’t apply, and how to create new primciples and process. Process does not take the place of skill – it accelerates, prevents people from reinventing every wheel that comes along. So what processes and concepts resonate with the people we asa UX professionals work wiith?
• #36: One key set of processes inherent to professional HCD relies on the concept of the three-legged stool. A solid HCD process ensures that all design rests on a set of processes and methods that allow you to understand three core elements of a product. The needs of the business. What are the business drivers behind the product? Why is money being spent to build the product in the first place? Make no mistake about it: The is always a business driver to any product development. We need to uncover it so we can consider those wants and needs as we design and build a solution. The technology. What are the constraints and enablers of the technology that will be brought to bear on the development of the product? And, of course, Who are the humans that will be affected by this new product? Who are the users?
• #37: To explain this concept I often use an example from my consulting. I was working with a colleague to help re-do the IA for the website of a sporting goods company. We did all of our customer research, and based on what we learned from the customer, we envisioned something like this, a very outdoorsy-looking home page, if you’re quiet you can almost hear the sound of crickets… Then we worked with our client stakeholders, interviewed them, listened to their needs. It turns out that in coordination with their website relaunch, they were also launching a new credit card…in fact, this was part of the funding rationale for the new website launch. In the client’s mind, the home page would look like this:
• #38: So, understanding the balance, and being able to explain this to your stakeholders, you can more effectively advise your client stakeholders.
• #40: OK, so after that last bit, it should be apparent that I’m a big fan of process. In addition to following existing processes, I believe that by virture of UX being a relativly new discipline, that we look for ways to not simply try to supplant existing ways of doing things, but instead, to Innovate. The first type of innovation I want to highlight is Method Innovation.
• #41: OK, so after that last bit, it should be apparent that I’m a big fan of process. In addition to following existing processes, I believe that by virture of UX being a relativly new discipline, that we look for ways to not simply try to supplant existing ways of doing things, but instead, to Innovate. The first type of innovation I want to highlight is Method Innovation.
• #42: A couple of examples – in 1997, I innovated a methodology called the 3x3. This was done in response to a few trends: One was that traditional UCD shops were up against agencies, competing for relevance. Agencies had resources traditional HCD folks couldn’t compete with. We had awesome reports. They had awesome mockups. We worked in words. They worked in pictures. We advocated for users. They appealed to the business. I created the 3x3 as a way to rapidly move from concept to design. I presented this at the UPA conference in 1997, in fact. I was working with agencies who, at the time, would take three comps and flesh them out a few screen deep and get a client approval. As a person who focuses on the customer, I took – you can say stole – that basic idea, and enhanced it with user feedback activities. In other words, I saw a need, and took the activities we already knew how to do, and shaped them to meet that need. This happens all the time, and helps us better engage, be
• #43: Go to the 1904labs website.
• #44: Go to the 1904labs website.
• #46: My current
• #48: We know how critical it is to have empathy for our users – but looking back at the three-legged stool, there are two other constituencies we need to interact with. The first are the techs.
• #49: We know how critical it is to have empathy for our users – but looking back at the three-legged stool, there are two other constituencies we need to interact with. The first are the techs.
• #50: It may seem that technologists don’t need the benefit of what we do Middleware Data engineering and Decision Science. We apply the same process to these projects, but the humans are often developers,