In the quiet of a crisp Minneapolis morning in November 2017, Zack Naylor stared at his laptop screen. An email had just blinked into his inbox, in reply to some routine customer research he was doing for his product strategy software, Aurelius. The sender line showed it was from one of their earliest customers, but it was the message itself that sent tingles down his spine.

“We’re actually exclusively using the beta now”.

At that time, Aurelius was product strategy software, just entering its third year. It had recently launched a beta version that reimagined the tool with a focus on research and insights. What made this email special was its confirmation that Aurelius customers were now using the beta—the optional beta—more than the product they were actually paying for. 

“It was an interesting, but also a very proud moment… It became very clear to us we should sunset the older product and focus everything on research and insights,” Zack told us.

It was the point where they pivoted direction, changing tack to become the popular research and insights platform we now know as Aurelius.

Planting the Seed: Zack’s Early Career

Zack describes himself in his early career as a “pretty good front-end developer, and an okay visual designer”. He was dabbling with an approach to design that didn’t really have a name or clear definition yet. He was working in start-ups, and through practical experience taught himself the principles of user research. Utterly fascinated, he read everything he could about what would later become popularly known as ‘UX’, working further back in the human-centered design process, starting with his design and development view until he was at the early stages of discovery and product strategy. As many UX professionals can relate, he got bitten by the UX bug and didn’t look back. 

Zack had UX experience working in both Fortune 500 and startup contexts, but it was with his move to Minnesota for a job at The Nerdery that many pieces fell into place for him. The Nerdery is a strategy, design and technology consultancy, and his role as the Principal UX Designer there gave him responsibility for up to 50 active projects across his team at any given time. What this meant, practically, was his ten thousand hours in teaching people and building a research practice.

“I realized that while I could teach anybody how to design, it’s much more difficult to teach people the right things to design.” 

He also realized that the best way to do this is by creating a design culture with a foundation of customer empathy backed by solid insights gathered from user research. 

The Nerdery gave him experience in helping people make the right decisions on designs, products, and features, and as a result, he discovered for himself the constants within this type of effort. “There are a number of patterns for how you ought to approach this work. It doesn’t matter where you are, what the industry is, what your team looks like… There are some pretty basic universal truths”. He wanted to help people make these decisions at scale, rather than have to hire someone every time. It was in this environment and way of thinking that he met his future business partner, Joseph Szczesniak, and Aurelius was born. 

Genesis of Aurelius

It was just before November 2015 that they were in Zack’s basement (surely a place where great ideas are born) discussing product strategy. “There’s got to be a way we can help people make these decisions better—like we did when we were actually hired to help them”. After an inevitable round of brainstorming, they emerged with some exciting concepts for building the software to help. 

Aurelius thus began as a product strategy platform that valued research and insights. A lot of hard work went into developing the idea and its execution, and things grew rapidly.

Juggling time while building Aurelius

Aurelius is 100% bootstrapped and self-funded – which means all the design mapping, UI creation, development, startup admin, problem solving, and everything else, happened on their own personal time. Zack would wake up at 4:00am to clock in on Aurelius for several hours, do a morning workout, and then go on to his day job. At night he’d get home to spend more time with his family, then make some more progress on Aurelius.

With two young kids—a one-year-old daughter and a six-year-old son—plus full-time work, commitments as the president of the UXPA, and all of the Aurelius workload, there isn’t much time leftover. 

“Any of my time and attention that does not go towards my family, Aurelius, or my full-time job; I basically don’t do”. 

Both co-founders are in Minneapolis, but much of Zack and Joseph’s connecting is done remotely. Despite being only 20 minutes away from each other, meeting online is much easier for simply getting things done.

Zack laughed when we asked where he got his energy and persistence from. He says it’s a matter of dedication; it’s because he loves what Aurelius does, and they really want to solve this problem with research, to help people and teams make sense of what they learn. 

This motivation is uncommon amongst a startup culture often driven by dreams of corporate takeovers and buyouts. Aurelius intends to remain self-funded. “We don’t want to take funding because both of us have worked in startups and seen how various levels of funding influence direction and priority and, quite frankly, mess up the direction of your product. That’s important to people like us because we are the people who do that work. We want to stay very true to solving that problem.”

As you’d find with many successful startups; it’s also about passion, “We work really hard learning from customers and folks in the industry to help Aurelius support successful products and successful companies. That’s what drives me.”

Motivation to solve the ResearchOps problem

You get another insight about what motivates Zack in the way he describes Aurelius as a vitamin;

“You may not feel like you need to take a vitamin today, but four or five years down the road, if you weren’t getting an essential vitamin, you’d really regret it.”

Aurelius helps you build a research repository so that you can come back and get even more out of the research you’ve already done. “When it comes to ResearchOps, InsightOps, and DataOps, there are great, sophisticated tools for doing the design. But we don’t have good, sophisticated tools for making sure we’re designing the right things. And that’s arguably much more important.” 

Zack suggests that most products fall on one side of the fence or the other: they are either a painkiller or a vitamin. Painkillers might suppress the problem for the time being, but vitamins keep the practice healthy for years to come. “Aurelius is very much a vitamin. It helps you grow your research practice into a healthy asset for the business.”

The Pivot: Moving from Product Strategy Tool to ResearchOps Engine

The original version of Aurelius was targetted to product strategy, and Zack estimates ten percent of signups wanted it just as it was. But it was the other 90% that often said things like ‘I love this. I wish we were mature enough to work this way. But tell me more about this research and insights piece that you’ve got’. Once they’d heard that more than a few times, Zack and Joseph got curious. There was a pattern of people struggling with organizing, applying, and getting more out of the research they had already done.

 “As you mature in research practice, the broader product strategy problem will actually start to become apparent.”

People were interested in the research and insights potential of Aurelius — but what was the solution? The decision was made to take it out and make it it’s own product: the beta version of Aurelius version 2 was a dedicated research and insights platform. While this was emerging they still had paying customers using the original version 1, but then came the moment that Zack will never forget. “It was one of those early mornings where I got an email from one of our first, early customers on Version 1. I was doing some regular customer research with them… and I remember them saying, ‘We’re actually exclusively using the beta right now’. They had paid upfront for a year’s license of Version 1, but were basically neglecting it for the beta of the new product.”

Their customers were using the new beta more than their paid product, justifying it by describing the purpose and supporting functionality as a better fit. It was a very proud moment for Zack. He followed it up with other existing customers “If we killed v1 tomorrow and just continued building this, would you even blink an eye?” The answer? No, they wouldn’t.

“It became very clear to us we should sunset the older product and focus everything on research and insights. And we’ve been far more successful as a result.”

The Shift: How Aurelius Changed

Aurelius reinvented itself as a research and insights platform with some novel approaches to solve traditional problems of user research analysis and synthesis.

In short, it helps you tag, analyze, organize, search, and share everything you learn from a qualitative research dataset. Notes, connections and patterns learned from customers, Aurelius helps speed up the process of discovery. 

By collating research in Aurelius, you automatically start building a research library. This holds some powerful potential. When asked what was learnt from a particular research project there are two common outcomes:

1. You weren’t the person who did the research, and maybe they’re gone, so a lot of the native fluency with the findings are lost. You may need to redo the research. Or,
2. What was learnt wasn’t captured in enough detail by the original report—so it’s only a snapshot in time.

With Aurelius, this isn’t a problem as it’s already been recorded and tagged, possibly even while still in the research session itself. The platform is flexible in how it can work, where you can add and connect key insights. You can take a bottom-up approach where notes can be used to create insights. It was intentionally built flexible enough for customers to do that.

It could also be described as a multi-functional note collation tool. Whether you’re recording research as transcripts, notes—or a mix of both—you can use Aurelius to tag as you record, and then theme and group thoughts you want to focus on and think about more deeply. It helps you see what you have and what you’re still missing, so you have more time to focus and work on your insights.

It also means more flexibility across design teams. You don’t need to just hand over a report; teams can explore and dig deeper into the original data, discovering new things of their own via tags and key insights in the project space. When teams have access to the entire, raw collection of evidence, organized in a way that’s easy to see, new opportunities for discovery can open up.

Zack recounts a story shared by a paying customer in the Version 1 days, who told him it was often ‘faster and easier’ for them to do a whole new research project than to put together learnings they had collected in past research.

“I mean, that just hit me like a ton of bricks because that should just never be true… As an industry we can do a better job than that. I got very passionate about tackling it, and today it’s one of the biggest reasons why people come to Aurelius.”

Aurelius supports user experience designers in the way they out to think.

“No single tool will make anybody good at UX design. I very, very strongly believe that. Simply put, Aurelius helps researchers do the work that they are doing today, but makes it faster and easier.”

The Meta of using Aurelius to build Aurelius

Zack and Joseph use their own platform daily, to understand future improvements for the Aurelius platform. “Everything I learned from customers, everything I learn even from prospects of the market, I use Aurelius projects to do that”

“We want research to actually inform the direction of where a company goes because these are the most successful products and companies in my opinion”.

Once teams have the ability to organize and do more things with the research and insights they have stored in a respository, then they’re able to consider the bigger picture, and ask for more of what they need from the platform. Ultimately, as part of Aurelius, Zack wants to support these people as genuinely as possible. And 99% of the time Zack is the one doing that; answering support questions, responding to feature requests, fixing bugs. “I take a lot of pride in the fact that people really appreciate it, despite how small we are. We care about what we’re doing and the people we’re trying to serve”. 

Both co-founders are clear about the problem to be solved: to help people make sense of what they learn. “User research is going to help you make better products, better features, better designs, better decisions. We’re just trying to help you do that faster”.

Mention UX Mastery to get 10% off any Aurelius plan, just email Aurelius after you sign up to claim the offer.

The post Living the change from Product Strategy to Research Ops: The Journey of Aurelius Labs appeared first on UX Mastery.

Customer experiences are increasingly complicated—with multiple channels, touchpoints, contexts, and moving parts—all delivered by fragmented organizations. How can you bring your ideas to life in the face of such complexity?  Rosenfeld Media – Orchestrating Experiences

We talked through this challenge with Patrick and Chris in our Slack channel today and it was an enlightening session. The questions were excellent, the advice practical and I came away feeling inspired to implement some changes into my own workplace.

If you didn’t make the session because you didn’t know about it, make sure you join our community to get updates of upcoming sessions.

If you’re interested in seeing what we discussed, or you want to revisit your own questions, here is a full transcript of the chat.

Transcript

hawk

2018-11-07 21:01

Show time

hawk

2018-11-07 21:01

First up, welcome to everyone that’s here.

hawk

2018-11-07 21:01

And a huge thanks for @risdon and @pq185 for giving time and wisdom today so that we can learn

hawk

2018-11-07 21:02

Chris and Patrick crossed our path recently when they published their new book https://rosenfeldmedia.com/books/orchestrating-experiences/

risdon

2018-11-07 21:02

Excited to be here!

pq185

2018-11-07 21:02

Hi everyone!

hawk

2018-11-07 21:03

Luke wrote a review of it here: https://uxmastery.com/book-review-orchestrating-experiences/
He’s a huge fan.

hawk

2018-11-07 21:03

Formal intros:

hawk

2018-11-07 21:03

Patrick Quattlebaum is a designer and teacher who gets up every morning to bring creativity, rigor, and humanity to problem-solving. He is the co-founder and CEO at Harmonic Design, a consulting firm based in Atlanta, GA, USA. Previously, he was principal designer at studioPQ, Managing Director at Adaptive Path, and Head of Service Design at Capital One.

hawk

2018-11-07 21:03

An expert in design strategy and service design, Patrick places a premium on pushing design practice to be more value-centered, collaborative, and iterative. He and his co-author, Chris Risdon, share their design philosophy and its practical applications in Orchestrating Experiences: Collaborative Design for Complexity.

hawk

2018-11-07 21:03

Chris Risdon is Director of Design for a peer-to-peer carsharing service, Getaround, and co-author of the book Orchestrating Experiences: Collaborative Design for Complexity.

hawk

2018-11-07 21:03

Previously, Chris was Head of Behavioral Design for Capital One and a Design Director for Adaptive Path, the pioneering experience design consultancy.

risdon

2018-11-07 21:03

Hello!

hawk

2018-11-07 21:03

Chris has introduced and advanced new methods in design, teaching thousands of design professionals and students. With a focus on designing complicated services and behavioral design, he has been published in a number of blogs, journals and magazines, as well as contributing to a number of books and articles. He’s spoken and taught workshops at conferences such as SxSW, UX Week, and IxDA’s Interaction Conference.

hawk

2018-11-07 21:04

And now I’ll be quiet and let the UXperts speak. Can you give us an intro to the topic please?

risdon

2018-11-07 21:04

Happy too!!

risdon

2018-11-07 21:05

The book we’ve written is fairly comprehensive.

risdon

2018-11-07 21:05

I don’t think we set out to make it so — we were after solving 3 challenges we were seeing in our work.

risdon

2018-11-07 21:06

Across our time together at a couple consultancies, plus in-house at a large financial institution…

risdon

2018-11-07 21:06

First, we noticed more than ever, good design at companies was a team sport.

pq185

2018-11-07 21:06

https://www.flickr.com/photos/rosenfeldmedia/26806707627/in/album-72157668191892598/

risdon

2018-11-07 21:07

Specifically cross-functional. People were in rooms together, who weren’t normally in rooms together, trying to figure out hard customer/user problems. Not just IT, UX, Product, but operations, customer service and other functions across the org.

risdon

2018-11-07 21:07

So the first challenge was the challenge of working collaboratively in this new world — particularly where these groups of people didn’t share the same process or language, etc.

pq185

2018-11-07 21:08

Not to mention work should be fun!

risdon

2018-11-07 21:08

The second challenge we saw was what we were actually designing for. Moving from *just* single touchpoints — say, a single digital product. But instead for *experiences* that spanned time, space, and most importantly different touchpoints and channels. Call centers, digital products, physical environments.

pq185

2018-11-07 21:08

https://www.flickr.com/photos/rosenfeldmedia/41634492722/in/album-72157668191892598/

risdon

2018-11-07 21:09

So we had more complicated experiences, with a collaborative cross-functional teams — those were the first two challenges. Once this group was in a room together solving for these complicated experiences, it brought about the third challenge we wanted to address in the book…

risdon

2018-11-07 21:10

The tools we use. We needed new tools, or to adapt the tools we use, or socialize existing tools with our new partners.

risdon

2018-11-07 21:10

By tools, I mean the methods, or process, or ways we approach solving for various parts of the problems.

pq185

2018-11-07 21:10

https://www.flickr.com/photos/rosenfeldmedia/39867371980/in/album-72157668191892598/

risdon

2018-11-07 21:11

We wanted to address those three problems – and as Patrick chimed in — this needed to feel like a fun, rewarding, way to work, or it just wouldn’t stick.

pq185

2018-11-07 21:12

The companies I’ve worked with talk a lot about being collaborative, creative, and customer-centric… and about solving complex problems. But., they aren’t very good at.

risdon

2018-11-07 21:12

The hardest part was deciding what to include and what not to include, because there are already so many good approaches to solving various challenges in the design process. Determine what to highlight that specifically address those challenges of cross-functional teams, working collaboratively with new shared tools to solve those complex experience challenges.

risdon

2018-11-07 21:13

They just don’t know what it looks like.

pq185

2018-11-07 21:13

Orchestrating Experiences is about changing how we work together and changing how we look at what we are designing together.

jakkii

2018-11-07 21:14

Relatable

risdon

2018-11-07 21:14

One thing I think both Patrick and I are most proud of is, even though there’s a lot of content there, we specifically made it practical — we’ve included specific workshop guides so people can go into rooms with these teams and feel armed with how to facilitate and meet team objectives.

pq185

2018-11-07 21:15

Yes. There are many example of deliverables and artifacts, but our goal was to help you get people in a room (or virutally) and work on these challenges together.

pq185

2018-11-07 21:15

I just stepped out of workshop for this chat in which 10 people from different functions are collaborating for how to create a new service and they need to work differently to pull it off.

risdon

2018-11-07 21:16

We frame any artifact not as a deliverable, but as a tool, and specifically seek to have anything we make (experience map, service blueprint, storyboards) be intended to use as a working tool.

pq185

2018-11-07 21:16

Yes! The workshop I just mentioned is using a journey model to plan out how they will each contribute to each customer moment and the intended outcomes.

pq185

2018-11-07 21:17

How they are making meal together, not each bringing something to the pot luck. :slightly_smiling_face:

risdon

2018-11-07 21:17

The image Patrick posted above — of an experience map with the stickies on it — is an example of this. When we created it, we specifically went through a working session to align on what the opportunities were and what principles should guide different steps in the journey.

pq185

2018-11-07 21:17

https://www.flickr.com/photos/rosenfeldmedia/26806706667/in/album-72157668191892598/

sarah.johnston

2018-11-07 21:18

@risdon – It seems like getting everyone in the same room together for a workshop when working on complicated experiences with a collaborative cross-functional teams seems like the key ingredient to success. I wonder if you could achieve the same success when you work with cross-functional teams that all live remote in different cities… :thinking_face:

hawk

2018-11-07 21:19

Ok – question time! Shoot…

risdon

2018-11-07 21:19

One thing to mention, we specifically wanted to blur the lines between UX, Service Design, and Customer Experience — all have influenced us and have important meaning and roles. In the case of this book, we just wanted to help designers of whatever tribe put these principles into action regardless of affiliation.

pq185

2018-11-07 21:20

And beyond designers. The goal was to propose common frameworks and language for the organization to truly collaborate around the same outcomes for customers, employees, and the business.

risdon

2018-11-07 21:20

Let me see if I’ll do this right…

@sarah.johnston asked… It seems like getting everyone in the same room together for a workshop when working on complicated experiences with a collaborative cross-functional teams seems like the key ingredient to success. I wonder if you could achieve the same success when you work with cross-functional teams that all live remote in different cities…

risdon

2018-11-07 21:22

The short answer yes! It can be a challenge, but definitely doable. We’ve set rooms up to help teams see each other, and had a home-base where the workshop was being facilitated.

risdon

2018-11-07 21:23

One of the keys is for remote participants to be prepped to still don some hands-on activities — such as writing things down on stickies.

glennveugen

2018-11-07 21:23

joining in from Amsterdam, been a while since I attended these talks :slightly_smiling_face:. @risdon @pq185 you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

tomstuder

2018-11-07 21:23

Do you use any collaborative software/apps to help facilitate workshops?

risdon

2018-11-07 21:23

Another are tools such as Mural (http://mural.co) and other virtual whiteboards, that allow collaboration.

hello207

2018-11-07 21:24

When I’ve done any kind of experience mapping in the past it’s always been with a particular user in mind that’s been backed up with qualitative research. If that kind of research is missing, and all we have is anecdotal experiences with the user is there any value in doing a service blueprint or journey map?

risdon

2018-11-07 21:25

@glennveugen First, we put a lot in the book, but we don’t prescribe that everything we cover needs to be in every project. So first is to make sure you’re only doing (and creating artifacts) that are needed. When someone says, we should do a journey map — ask what the purpose is for? Is it for organizational planning?

andrew.schadendorff

2018-11-07 21:25

@risdon @pq185 the biggest challenge I have at my company is getting stakeholders time and energy. What are your key tips for getting buy in across the organisation and linking these workshops to financial kpis?

risdon

2018-11-07 21:25

Or to understand the experience?

pq185

2018-11-07 21:25

@glennveugen you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

Often, the artifacts are tested out as a tool before being completed. It’s basically usability and usefulness testing. With experience maps, I often make an initial version, use it in a workshop, refine it, and then distribute with instructions on how to use in strategy and design activities. Testing it out also is a way of teaching people how to use them.

risdon

2018-11-07 21:25

Or to align people to get buy in on doing additonal work. When you determine that you can plan ahead on how you will use it as a tool to be a catalyst for the next steps.

pq185

2018-11-07 21:26

@glennveugen you mention you encourage the use of your artifacts as tools. How do you ensure these deliverables are actually used in the further stages of a project, i.e. the delivery phase?

The other appraoch is to create living documents rather than static ones. I’ve been experiement with digital tools that position blueprints or storyboards as objects that dowstream requirements and design artifacts are connected to.

risdon

2018-11-07 21:27

@hello207 When I’ve done any kind of experience mapping in the past it’s always been with a particular user in mind that’s been backed up with qualitative research. If that kind of research is missing, and all we have is anecdotal experiences with the user is there any value in doing a service blueprint or journey map?

risdon

2018-11-07 21:27

To answer your question @hello207…

zimmerman1181

2018-11-07 21:27

@risdon you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

risdon

2018-11-07 21:28

Re: Service Blueprint — yes! Service blueprints aren’t qualitative…they are about what are the processes, people, technology, to support a service. You can always do those, without research.

risdon

2018-11-07 21:29

Re: journey/experience map @hello207 — it is more of a challenge. What you can do is create a “proto” journey map — one framed specifically being from internal knowledge, but not fully fleshed with the qualitative and quantitative data you might need.

risdon

2018-11-07 21:29

And then you use that proto-map to highlight gaps in knowledge, and possibly get buy in to do focused research in that area.

risdon

2018-11-07 21:30

@zimmerman1181 you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

pq185

2018-11-07 21:30

@hey the biggest challenge I have at my company is getting stakeholders time and energy. What are your key tips for getting buy in across the organisation and linking these workshops to financial kpis?

When a culture is not used to collaborating, workshops can be challenging. It’s like going to the gym for the first time after sitting on the couch and watching TV for year.

With workshops, you have to design the experience before, during, and after to carefully set expectations on the benefits of blocking out a day and getting away from their devices. You have to ask for feedback throughout the session to ensure people are having a good experience. And then gaving participants help spread the word that’s it worth the time.

I’ve not had to develop specific KPIs. Typically, the word of mouth after a well designed workshop helps get more people interested in being in the next one.

sarah.johnston

2018-11-07 21:31

To piggyback off of this comment, any collaborative software/apps that might help facilitate workshops for remote teams?

risdon

2018-11-07 21:31

I mentioned a bit above @zimmerman1181 — but it’s planning ahead to determine and get alignment on why *exactly* you want to do an exercise that will produce a specific deliverable (why a persona, why a journey map, why a service blueprint), and once you know that, you can plan ahead what type of working session/workshop you might do once that’s produced in order to drive the next phase.

harpo

2018-11-07 21:31

To the above point, I work closely with engineering folks, and encounter sometimes severe cynicism or resistance to these types of show-and-tell exercises. Some will hate you for forcing them into any new bureaucratic process, they feel are a waste of time thereby undermining your future good will to GSD. How do we demonstrate ROI, or make the case for participation. Does it have to be top-down?

risdon

2018-11-07 21:32

An experience map can help determine where to prioritize opportunities, or define experience principles which will guide new solutions — so if you know your producing an experience map to be a catalyst for those things, you’re using that map as a tool.

pq185

2018-11-07 21:32

@zimmerman1181 you said earlier “We frame any artifact not as a deliverable, but as a tool…” could you elaborate on that idea a little bit more, please?

Often things—maps, blueprints, storyboards—are made to document previous activities, but they are also props to engage stakeholders in downstream activities. So, you have to think about not just how the artifact is used to understand previous thinking, but also as a way to support the next steps of design process.

risdon

2018-11-07 21:34

@harpo – to your question about resistance, it’s a good point. We definitely can’t prescribe a silver bullet for getting buy-in. You have to have people that are at least *a little* receptive to the idea of doing new thins in new ways to get to better outcomes — similarly when teams want to apply new approaches, like Lean, or Dual Track Agile, or JTBD — all new approaches that require buy-in.

dave

2018-11-07 21:34

@risdon @pq185 Have you found that you can apply experience mapping across orgs in all industries? Would it be specific/unique to that industry?

e.g. Non-profit would be different than Oil & Gas corp.

sarah.johnston

2018-11-07 21:34

@harpo I’m having the same problem at my organization… but it’s not just the devs, it’s the product owners that are driving our UX projects that don’t see value in workshops like these. They think it’s a waste of time unless additional requirements come out of them that they haven’t already documented from their “research”.

risdon

2018-11-07 21:35

But, it first has to start with conversations, and then ideally doing something really small, but with a measurable outcome. But I also try to develop a strategy for getting buy-in, give myself a timebox for seeing some results (say 6-9 months, since things can move slowly), and if I don’t get traction, I get a sense of whether this org will ever change. Sometimes change is just slow, other times its hard, and other times it just won’t happen.

pq185

2018-11-07 21:36

@harpo To the above point, I work closely with engineering folks, and encounter sometimes severe cynicism or resistance to these types of show-and-tell exercises. Some will hate you for forcing them into any new bureaucratic process, they feel are a waste of time thereby undermining your future good will to GSD. How do we demonstrate ROI, or make the case for participation. Does it have to be top-down?

To some degree, top down helps not in any particular instance of collaboration, but culturally in that each discipline should be experimenting with its practice to find new ways to be more effective and/or efficient. If there isn’t support/expectation of continually improving how you work, then you do risk resistance when you try to.

The other thing to keep in mind is to be clear about which methods are to support what outcomes. To zoom out and look at the journey of the customer when the product team focuses on one small part does require the right buy in for the value of zooming out.

risdon

2018-11-07 21:37

@harpo if you work in a product-centric environment, then the most important person to get buy-in from is your product manager. If you can find something small, but with a measurable outcome, then they will often buy-in.

pq185

2018-11-07 21:38

@dave Have you found that you can apply experience mapping across orgs in all industries? Would it be specific to that industry? e.g. a non-profit would be different than an Oil & Gas corp.

Experience mapping is a very felxible approach that is about experience over time. As long as you have a person who experience crosses channels and touchpoints and whose context is greater than just the product or service (it always is), then experience mapping can be valuabel exercise.

pq185

2018-11-07 21:38

https://www.flickr.com/photos/rosenfeldmedia/41634480682/in/album-72157668191892598/

risdon

2018-11-07 21:39

@dave Have you found that you can apply experience mapping across orgs in all industries? Would it be specific to that industry? e.g. a non-profit would be different than an Oil & Gas corp.

I think yes, it can be — the key is if there’s a journey to support. For example, pure digital products that want eyeballs — like Twitter, or Slack, etc. — may/may not need a journey map. But things that have operations, or an array of touchpoints (digital app, website, mailed bills, customer service) often can benefit from understanding the experiences people have with the product/service over time. It may not always feel like a linear journey, but it can benefit mapping out what people are thinking, feeling, and doing at different times.

hawk

2018-11-07 21:39

We’re at the end of the question queue. Keep ’em coming.

harpo

2018-11-07 21:39

@risdon I agree with the methodology, I think it’s a positive net result. Just wondering if there are studies that prove it changes culture, in terms of either employee evaluation, or just bottom line profit, or shorter time to market. Thank you for your tips and presentation, good food for thought

pq185

2018-11-07 21:40

https://www.flickr.com/photos/rosenfeldmedia/40784035785/in/album-72157668191892598/

sarah.johnston

2018-11-07 21:40

@risdon – if you ever discover a silver bullet for this, I’d love to know! :wink:

risdon

2018-11-07 21:40

One way, from a UX perspective, is to think about empathy maps — which can often help understand what someone is experience at a certain moment or environment…

risdon

2018-11-07 21:41

Once you know you have many of these (when someone onboards, when someone pays a bill, when someone calls, when someone checks out on the app), you can imagine having some understanding of this string of empathy maps to tell a larger story.

pemarroquin

2018-11-07 21:42

I think workshops should be part of the research, I’ve had experiences where admins and other professionals, share their experiences with much greater details in group. I think is because people like telling stories.

pemarroquin

2018-11-07 21:43

Love that everything discussed is pure design thinking

pq185

2018-11-07 21:43

@pemarroquin yes, and it’s also about systems thinking.

risdon

2018-11-07 21:43

That’s a good question @harpo — I don’t have any studies on that. I have found people love working with each other and enjoy breaking some silos, but no specific studies. Related, there is a book called Outside-In, focused on Customer Experience, that does cite studies showing customer-centric companies do better on the stock market. I cite that a lot for evidence of being more human-centered.

pq185

2018-11-07 21:44

@pemarroquin when you start digging into ecosystems and organizational culture, you’re really going beyond design thinking and crossing over into some other methods and toolkits.

risdon

2018-11-07 21:45

One reason we’re a fan of the journey framing is because it can be this hub of empathy, understanding, and strategy — we have found that different parts of an organization are experts at a distinct part of the system/experience, but everyone lacks a holistic view. When you get people aligned on a journey, they can see the whole, and how their part is connected to, and influences, the other parts.

pq185

2018-11-07 21:46

Outside In –> https://www.amazon.com/Outside-Putting-Customers-Center-Business/dp/1491514221

risdon

2018-11-07 21:46

That will lower silos just a bit.

pemarroquin

2018-11-07 21:46

That’s interesting! @pq185 the need of both worlds so the output’s quality can be assured

pq185

2018-11-07 21:47

https://www.flickr.com/photos/rosenfeldmedia/40784029765/in/album-72157668191892598/

risdon

2018-11-07 21:47

Then when you’ve aligned on what people are experiencing — what people are thinking, feeling, and doing — across that journey, you can zoom in — design a specific touchpoint with better understanding of context, and how it’s connected to what happens before it, and after it…

risdon

2018-11-07 21:47

Or zoom up, and have more insight to help planning, roadmapping, having conversations with parts of the org for solutins that are dependent on each other, or start to transform/change the org.

risdon

2018-11-07 21:48

Depending on what area of focus you are responsible for.

risdon

2018-11-07 21:49

What hasn’t come up yet, is downstream — really getting a shared ‘north star’ — as people need to go to their silos to execute, if you all share in understanding what future you are heading towards, you can make better independent decisions as you go to your respective areas to execute.

pq185

2018-11-07 21:49

levels of zoom is a powerful conceptual model we talk a lot about in the book. our former colleague, Brandon Schauer, wrote a nice medium post about the topic. https://medium.com/@brandonschauer/design-leadership-tricks-zoom-out-1x-33017513c650

hawk

2018-11-07 21:49

I can imagine that sometimes bringing cross functional teams together to collaborate could result in frustrations. e.g. “the developers aren’t really listening to me”. Is the outcome of this kind of work always positive in your experience?

risdon

2018-11-07 21:50

Nice question @hawk If you start asking people to show up to working sessions without getting buy-in or prepping them for what the larger purpose is, then you can really have a negative experience.

risdon

2018-11-07 21:51

One reason to start small, you can tackle principles and activities from the book in as little as two weeks.

pq185

2018-11-07 21:51

@hawk it’s a bell curve with participants. not everyone is an innate or positive collaborator. so you always run into some friction. In the grand scheme of things, collaboration as a skill is more and more expected in organizations. You have to push against the business as usual and keep modeling how we should work. it will be good for your career.

hawk

2018-11-07 21:52

Ok everyone, we have 5 minutes left in the session! (Where has that hour gone?)
Any last questions? Now’s your chance…

pq185

2018-11-07 21:53

@hawk the other thing to keep in mind that collaboration and innovation require different people to participate. it shouldn’t just be product and developers. experiences are bigger than product and technology so it’s best to have other functions involved.

risdon

2018-11-07 21:53

There are also ways to bring people along for the ride. I have been surprised how many developers ask to sit in — as a notetaker — on customer interviews. If they have zero interest, that will tell you a lot. If they are interested, then that’s a great first activity for them to get exposed to this part of the design process, without really affect anything in their day-to-day work.

sarah.johnston

2018-11-07 21:53

How would you recommend bringing cross-functional teams together when those teams work remote in different cities? I feel like that adds to the challenge significantly.

hawk

2018-11-07 21:54

Good question!

hawk

2018-11-07 21:54

My org is fully distributed

innerpeacesjc

2018-11-07 21:55

Thanks for your insights! I was wondering if you have any book recommendations on this topic. Thanks!

zimmerman1181

2018-11-07 21:55

What kind of expectation setting do you do or “pre-work” do you have folks do prior to workshops?

risdon

2018-11-07 21:56

It is definitely a challenge @sarah.johnston — it adds to the difficulty. One way I have started small is to use a tool like Mural to do sprint retros — it gets everyone used to collaborating on a document (or in a virtual space) together, instead of editing a Paper/Google doc, or watching someone update a Confluence page…

pq185

2018-11-07 21:56

@sarah.johnston video meetings with screen sharing is a key. having facilitators in each location also helps. also having people work on paper tools and then sending to one location to print and display; or using tools like Mural for building things together.

sarah.johnston

2018-11-07 21:56

Also, like others that have mentioned in this thread, in addition to dealing with the challenge of working with cross-functional remote teams, I too am dealing with resistance with getting stakeholders to participate in collaboration activities such as workshops. Our product owners think workshops like journey mapping and especially empathy mapping are a waste of time :disappointed:

risdon

2018-11-07 21:57

As they do something small in that virtual space, it won’t be so abstract to say you’re going to review a journey map there, and everyone will label what they see as an opportunity area, and then to do a prioritization on opportunity areas (as an example of something I’ve done recently)

pq185

2018-11-07 21:57

@sarah.johnston
REMOTE WORKSHOPS
Before moving on to the last workshop of the book, I’d like to put in a good word for remote workshops. While it’s more effective to get people in a room together to collaborate, your timeline or budget may not accommodate this idea. Here are a few tips when you need to go remote:
•
Keep it hands on. While remote collaboration tools (in which you type and move objects around digitally) have some benefits, they lack the tactile interactions that come with analog tools. A better approach is to use video to see one another and show your work, while still having people work through exercises with paper tools.
•
Give yourself more time for activities. Everything takes longer to do in remote sessions due to lagged communications and synthesis steps that require more time in this format. You may have to split what would be one in-person workshop into a couple of shorter sessions to keep peak focus, energy, and attention.
•
Design templates. Without you in the room, people need more instruction and structure to work effectively. For this reason, avoid blank sticky notes as much as possible. Design simple templates with instructions that help people understand the form their ideas should be documented in.
•
Leverage mobile phones or scanners. Many ideation methods follow a generation and then evaluation cadence. In remote sessions, have participants work individually and then send in photos or scanned documents of their work. Give them a break, and then magically print and cut their work and place it on a large board. You can then walk through the items on camera, moving and organizing them as people give input and see the results.
•
Train cofacilitators. If possible, assign and prep cofacilitators at each stakeholder location.

sarah.johnston

2018-11-07 21:58

@pq185 – Thanks for the tip. I feel like we need to hone in on a good collaboration video sharing software that aids collaboration and do testing prior to make it easier for remote teammates to participate in the workshop activities.

zimmerman1181

2018-11-07 21:58

other than their’s of course. Haha. :joy:

pemarroquin

2018-11-07 21:59

Nice @pq185 ! :ok_hand::skin-tone-2::clap::skin-tone-2::clap::skin-tone-2:

sarah.johnston

2018-11-07 21:59

@pq185 – Thanks for providing this info!

risdon

2018-11-07 21:59

I wish I had a silver bullet for that @sarah.johnston I feel your pain. I’ve been fortunate to have success with this, but I haven’t had success every time. Earlier I mentioned, you likely need to define a strategy for getting people to buy into it, and give yourself a timeframe. 6 months? 12? you’ll determine. There are cases where an org just isn’t receptive to change. You need buy-in *somewhere* — the middle (product managers, team leads, etc.) or from the top. You try small, with little impact to the status quo, and if you can’t get traction over a certain time, there is a point where the org may just not accept that change.

hawk

2018-11-07 22:00

Ok team, we have time for Yancy’s question and then we’ve hit the top of the hour!

zimmerman1181

2018-11-07 22:01

I’m also ok if you just hit up @innerpeacesjc’s question about book recommendations.

pq185

2018-11-07 22:01

@zimmerman1181 What kind of expectation setting do you do or “pre-work” do you have folks do prior to workshops?

It depends on the session, but a minimum is prepping them for what inputs are being leveraged for the session. Distributing prior research, for example. Sometimes, I also assign so solo activities to bring to the session. Such as bringing in ideas based on a prompt.

sarah.johnston

2018-11-07 22:01

@risdon – That’s the sad truth!

pq185

2018-11-07 22:02

Book recommendations:
Meeting Design
Service Design Thinking
Service Design Doing

risdon

2018-11-07 22:02

Living in Information (Jorge Arango)

pq185

2018-11-07 22:03

Especially https://rosenfeldmedia.com/books/meeting-design/

pq185

2018-11-07 22:03

Given all the questions about creating engaging sessions!

risdon

2018-11-07 22:03

I’ve got one more tip for getting buy-in…

hawk

2018-11-07 22:03

We had Jorge in this channel last week.

hawk

2018-11-07 22:04

The transcript of that session is here https://uxmastery.com/transcript-living-in-information/

risdon

2018-11-07 22:05

If you’re working with product people, they are often data centric. If you’re expecting them to buy into your human-centered tolls and processes, you should meet them halfway, and buy into their data analytics. Bone up on data analysis and business intelligence, so you can speak their language, and they will likely relate to you and see you aren’t saying that they’re doing something wrong and you want to introduce something right, but that you both share in expanding your toolkit for better outcomes.

hawk

2018-11-07 22:05

Excellent tip!

hawk

2018-11-07 22:06

Thanks so much for that (and all the other wisdom shared today).

hawk

2018-11-07 22:06

It’s been an honour to have you both here.

hawk

2018-11-07 22:06

I’ve learned a lot.

pq185

2018-11-07 22:06

Ok gang, I have to get back to a workshop

risdon

2018-11-07 22:06

I enjoyed this a lot!

harpo

2018-11-07 22:06

Thank you!

The post Transcript: <em>Ask the UXperts:</em> The simple philosophies for successfully delivering complicated experiences — with Patrick Quattlebaum & Chris Risdon appeared first on UX Mastery.

Lou was talking about a topic which he is passionate about, and it was obvious.

Despite their heavy investment in research, large organisations still face an insight gap, which can gravely curtail product success. Lou believes the time is ripe for InsightsOps: the synthesis and operationalisation of research—currently locked in silos—that can lead to true insights across the organisation.

So that is what we learned about today.

If you didn’t make the session because you didn’t know about it, make sure you join our community to get updates of upcoming sessions.

If you’re interested in seeing what we discussed, or you want to revisit your own questions, here is a full transcript of the chat.

But first… here are the images referred to in the transcript:

Image 1
Image2
Image3
Image4
Image5
Image6
Image7
Image8
Image9
Image10
Image11

Transcript

Lou Rosenfeld

2018-05-16 21:01

Greetings from Brooklyn, NY.

Lou Rosenfeld

2018-05-16 21:01

…USA

Lou Rosenfeld

2018-05-16 21:01

I shouldn’t forget that.

luked1uk

2018-05-16 21:01

Welcome Lou

hawk

2018-05-16 21:01

Hello all – thanks for joining us today, and mostly a huge thanks to Louis for his time. It’s greatly appreciated.

hawk

2018-05-16 21:01

So the formal intro: Lou Rosenfeld is Rosenfeld Media’s founder and publisher. Like many user experience folk, Lou started somewhere (library science), made his way somewhere else (information architecture), and has ended up in an entirely different place (publishing).

hawk

2018-05-16 21:01

Lou spent most of his career in information architecture consulting, first as founder of Argus Associates and later as an independent consultant. He co-founded the Information Architecture Institute and the IA Summit. And he does know something about publishing, having edited or co-authored five books, including the IA “bible,” Information Architecture for the World Wide Web, and Search Analytics for Your Site. He tweets @louisrosenfeld

hawk

2018-05-16 21:02

And with that, I’ll ask Lou to give us some insight into today’s topic

Lou Rosenfeld

2018-05-16 21:02

Lou uploaded IMAGE1 and commented: My epitath

Lou Rosenfeld

2018-05-16 21:03

Really, that’s what most people know me for.

Lou Rosenfeld

2018-05-16 21:03

It gets a little unsettling, as I did the bulk of my writing on it about 20 years ago.

Lou Rosenfeld

2018-05-16 21:03

I don’t want to be a one-hit wonder.

Lou Rosenfeld

2018-05-16 21:03

So here I am, talking with you about some other new-fangled thing that most people will say–as with IA–doesn’t exist, or is not important.

hawk

2018-05-16 21:03

Maybe you could write about some other kind of bear then?

Lou Rosenfeld

2018-05-16 21:03

What would an insight bear look like?

Lou Rosenfeld

2018-05-16 21:04

I’m not even sure bears have good vision.

Lou Rosenfeld

2018-05-16 21:04

Though they are fast, can climb, and are lethal.

Lou Rosenfeld

2018-05-16 21:04

Anyway…

Lou Rosenfeld

2018-05-16 21:04

Here’s the story…

Lou Rosenfeld

2018-05-16 21:04

Around ten years ago, I was an indy IA consultant, working with Fortune 500s and government agencies.

Lou Rosenfeld

2018-05-16 21:05

You could have called me an “information therapist” at that point, because I was getting to do precious little IA, and mostly trying to make my clients feel better about the fact that they had precious little opportunity to help their organizations provide a better user experience.

luke

2018-05-16 21:05

But their foraging techniques and scent are great :rolling_on_the_floor_laughing:

Lou Rosenfeld

2018-05-16 21:06

I would always start them off with the request to see their user research. Because, of course, if you’re going to try to get an organization to change, you’ve got to have evidence to prove that things are shitty for customers, and that they could be improved.

Lou Rosenfeld

2018-05-16 21:06

Not to mention HOW the experience could be improved.

Lou Rosenfeld

2018-05-16 21:07

As I worked with these large orgs, I found that there was no shortage of user research. In fact, they were spending HUGE amounts on different kinds of user research.

Lou Rosenfeld

2018-05-16 21:07

Only it wasn’t always called user research. Sometimes, they called it market research.

Lou Rosenfeld

2018-05-16 21:07

Sometimes Voice of the Customer research.

Lou Rosenfeld

2018-05-16 21:07

Sometimes it was locked up in the analytics group.

Lou Rosenfeld

2018-05-16 21:07

Sometimes there were multiple user research groups.

Lou Rosenfeld

2018-05-16 21:08

There were brand research projects going on.

Lou Rosenfeld

2018-05-16 21:08

And on and on. No shortage of information on the what and why of what customers wanted, need, and how they were behaving.

Lou Rosenfeld

2018-05-16 21:08

You with me so far, @channel?

hawk

2018-05-16 21:08

I am.

luked1uk

2018-05-16 21:08

yep! :smile:

gary.bunker

2018-05-16 21:08

Absolutely

Lou Rosenfeld

2018-05-16 21:08

Cool. (Can be hard to type into the ether.)

Lou Rosenfeld

2018-05-16 21:09

Biggest problem is that the research was almost completey siloed.

luked1uk

2018-05-16 21:09

who you calling an ether :stuck_out_tongue:

Lou Rosenfeld

2018-05-16 21:09

Different tribes/disciplines using different methods and techniques to produce different types of data in order to learn different things about the same people.

Lou Rosenfeld

2018-05-16 21:09

And that takes me to a fable. I wonder if you’re familiar with this one?

Lou Rosenfeld

2018-05-16 21:10

(Give me a sec to grab the image.)

Lou Rosenfeld

2018-05-16 21:10

Lou uploaded IMAGE2

hello107

2018-05-16 21:10

has joined #ask-the-uxperts

Lou Rosenfeld

2018-05-16 21:10

This is the blind men and the elephant.

Lou Rosenfeld

2018-05-16 21:10

If you don’t know this fable (and I’m actually surprised it’s not better-known), let me tell you the story.

Lou Rosenfeld

2018-05-16 21:11

Bunch of blind men, out for a stroll. Seriously, no sighted person to guide them. Don’t ask me why, sounds hazardous.

Lou Rosenfeld

2018-05-16 21:11

They find themselves in the jungle. Like I said, sounds quite dangerous.

Lou Rosenfeld

2018-05-16 21:11

They encounter an elephant. But, of course, they can’t see the elephant.

Lou Rosenfeld

2018-05-16 21:12

One touches the elephant’s trunk. “It’s a snake!”

Lou Rosenfeld

2018-05-16 21:12

Another touches the elephant’s leg. “No, no, it’s not a snake–it’s a tree trunk!”

Lou Rosenfeld

2018-05-16 21:12

And so on.

Lou Rosenfeld

2018-05-16 21:12

Not one of them has the truth. No real insight.

heath.alexander

2018-05-16 21:12

My kids have a book by Ed Young that’s a retelling of that fable, https://www.amazon.com/Seven-Blind-Mice-Caldecott-Honor/dp/0399222618/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=&sr=

Lou Rosenfeld

2018-05-16 21:13

It’s only after they talk to each other, share information, and figure things out together that the arrive at true insight: it’s an elephant.

martina.net

2018-05-16 21:13

has joined #ask-the-uxperts

Lou Rosenfeld

2018-05-16 21:14

That’s called synthesis. And it’s something that we don’t really do in most organizations, especially large ones, and for that reason, we’re missing out on the Big Insights. We’re not working or spending wisely or efficiently. This needs to be addressed somehow, and it’s not easy. In the least

Lou Rosenfeld

2018-05-16 21:14

I only use the term–and hesitatingly–of InsightOps to draw attention to this problem. Because we need to go at it consciously. Its a design challenge, and an organizational change problem. And a bunch of other problems to boot.

Lou Rosenfeld

2018-05-16 21:15

I’ve been talking about this for about five years–I’m kind of a broken record in that I keep giving pretty much the same talk about it at conference keynotes.

meganweise

2018-05-16 21:15

But it is still so so important, please keep talking about it!

Lou Rosenfeld

2018-05-16 21:15

The good news is that more and more people seem to share this same concern. I’m starting to see them address it. I’m hoping to talk about it here with you and see if you’ve encountered similar problems.

Lou Rosenfeld

2018-05-16 21:16

Let me share a couple links, and then let’s talk. I have some ideas for solutions that I can get into later, but I want to open things up–in just a second.

Lou Rosenfeld

2018-05-16 21:16

Here’s a video of me giving a talk on this: https://www.youtube.com/watch?v=-LRdCAWz1pI

lindamanofficial

2018-05-16 21:16

has joined #ask-the-uxperts

Lou Rosenfeld

2018-05-16 21:16

Here’s a corresponding deck: https://www.slideshare.net/lrosenfeld/beyond-user-research

Lou Rosenfeld

2018-05-16 21:17

And an ALA article (getting a little old now): https://alistapart.com/article/seeing-the-elephant-defragmenting-user-research

Lou Rosenfeld

2018-05-16 21:17

OK, let’s discuss! Is this something you’re struggling with?

hello107

2018-05-16 21:17

Going through it right now, where even in a 150+ people organization our UX researcher used to work in a silo for 2 weeks and then come back with a deck + showreel from usertesting for a day. Everyone would watch, give comments and then walk away.

dave

2018-05-16 21:17

My teammates Teena Singh and Greg Petroff say Hi :wave:

gary.bunker

2018-05-16 21:17

Yep, same here

Lou Rosenfeld

2018-05-16 21:18

Hi Teena and Greg! Love those folks.

david.balcak

2018-05-16 21:18

has joined #ask-the-uxperts

Lou Rosenfeld

2018-05-16 21:18

@gary.bunker Where are you seeing it? (Willing to disclose?)

hello107

2018-05-16 21:18

I started with a framework inspired by Tomer Sharon, used airtable to democratize atleast the input part + access to user research insights. Even that small 2 day effort has helped quite a bit.

gary.bunker

2018-05-16 21:18

Forgetful organisations too – they run research, go ‘aaaahhh!’ then get new jobs. 12 months later, nobody even knows they ran the research

Lou Rosenfeld

2018-05-16 21:18

Yes, I’m a big fan of Tomer’s work (we published his last book, Validating User Research).

richard

2018-05-16 21:18

I am not 100% sure I understand. Let’s say my team does a GV style sprint, which means we’ll be doing user interviews to help diagnose a particular design problem, recording it, with a room full of people in the other room furiously taking notes all over the wall on post-its about that user’s experience. After five or so of these interviews, we have a clear direction for our design, and we make some changes. And then all the “noise” knowledge – everything except the decisions themselves – go down the tube.

Are you talking about putting that insight to broader / longer-term use?

hello107

2018-05-16 21:18

I read it!! :raised_hands: Great one!

Lou Rosenfeld

2018-05-16 21:19

He makes the point that @gary.bunker is making: lack of InsightOps/ResearchOps leads to a failure in organizational memory.

Lou Rosenfeld

2018-05-16 21:19

Here’s a link to one of his articles; he’s done a lot more in Medium: https://medium.com/amplify-design/polaris-research-ops-by-wework-e1fb54bc99ac

luked1uk

2018-05-16 21:19

I think the problem is different teams in one company can have different goals. in my last job the marketing team did a ton of user research that was pretty much almost useless to us on the ux team.

hello107

2018-05-16 21:19

Yes Polaris! :slightly_smiling_face:

Lou Rosenfeld

2018-05-16 21:20

@richard Yes.

Lou Rosenfeld

2018-05-16 21:20

There are cases in whch your team would have greatly benefitted from another team/researcher’s data–AND perspective on the problem. And vice versa.

gary.bunker

2018-05-16 21:20

Same here. I’ve seen huge decks with massive data on segmentation and responses and emotive mapping that has literally nothing in there to help design or improve an experience.

Lou Rosenfeld

2018-05-16 21:20

In fact, you probably would have had a better outcome if you’d had more blind men at the table, sharing notes and data and sythesis.

richard

2018-05-16 21:21

So, something _other_ than rolling up all the giant papers covered in post-it notes in long scroll-like tubes, and stashing them all in a bin in the corner, running off with our new direction for our 12 person product team given our specific goals for the month.

Lou Rosenfeld

2018-05-16 21:21

Now, without some sort of infrastructure and conscious effort, @richard will have no idea that other teams are doing relevant work.

richard

2018-05-16 21:21

Got it

Lou Rosenfeld

2018-05-16 21:21

Hah! Yes

gary.bunker

2018-05-16 21:22

Having a single sharable location for insights and research can help – bringing the blind men together for lunch each day to report on findings

Lou Rosenfeld

2018-05-16 21:22

It does, @gary.bunker But it’s not just an issue of having a giant repository, a la Polaris (or Aurelius or HandRail, to name a couple new commercial entrants into this space).

richard

2018-05-16 21:22

Can these insights get rolled up into our broader personas and other high-level artifacts?

Lou Rosenfeld

2018-05-16 21:22

It’s also critical to acknowledge that we 1) don’t know about each other, especially in large orgs.

Lou Rosenfeld

2018-05-16 21:23

2) We don’t speak the same language–given that we come from different tribes.

Lou Rosenfeld

2018-05-16 21:23

3) We don’t have common motivations.

luke

2018-05-16 21:23

I have worked at large companies and now at a startup. With many different and common challenges. I have actually pivoted my career into a product role to be able to create space for researchers in my team to influence the workspace. I think the more we separate ux as a separate function the more harm we sometimes do

luked1uk

2018-05-16 21:23

What I would love to see is 1 person for each team/department come together to do a user research study, that way you get all corners covered for what ever it is people want to get from their own users. I think that would work way better than 1 team doing it themselves, but that would require company organisation and strategy. thoughts Lou

Lou Rosenfeld

2018-05-16 21:23

“company organisation and strategy”

hello107

2018-05-16 21:23

Much like branding, I feel if the key stakeholders have not bought into what the process is, how it impacts the workflow/product and the resources needed to keep it going – it would end up on the bookshelf. – an issue pronounced in larger orgs.

crystal

2018-05-16 21:24

When we finally do know about each other, we don’t know each other well enough to realize we’re working on the same/adjacent projects where we could each benefit from sharing

Lou Rosenfeld

2018-05-16 21:24

Exactly, @luked1uk; that’s why I say it’s not enough to have a repository. Just like DesignOps is more than pattern libraries and design systems, you’ve got to have people responsible for guiding principles, strategy, and organizational change in order to make this work.

Lou Rosenfeld

2018-05-16 21:24

Exactly, @crystal

Lou Rosenfeld

2018-05-16 21:25

@hello107 In branding, we’re seeing a growth in “CreativeOps”. On the product side, “DesignOps” (in fact, my company puts on the annual DesignOps conference in NYC in November).

Lou Rosenfeld

2018-05-16 21:26

Of course, there’s (very suddenly) huge energy and engagement in the nascent ResearchOps community.

Lou Rosenfeld

2018-05-16 21:26

We need to take that operational goodness and keep extending it.

luke

2018-05-16 21:26

Why would a research ops and design ops be separate?

Lou Rosenfeld

2018-05-16 21:26

Lou uploaded IMAGE3

hello107

2018-05-16 21:27

ooooh!

Lou Rosenfeld

2018-05-16 21:27

@luked1uk Not sure they should be. In fact, at our conference they’re very much combined, in terms of the program.

Lou Rosenfeld

2018-05-16 21:27

But sometimes we separate things that are closely related simply to get a better look at them.

hello107

2018-05-16 21:27

This is an amazing representation Lou :raised_hands:

luked1uk

2018-05-16 21:27

I can see benefits to outsourcing this stuff sometimes for some companies. I love meeting my users and throwing them into tasks and watching them do stuff. Lou Do you think that sometimes out sourcing might be a better way to go? or is it vital that people understand their own users from their own research?

Lou Rosenfeld

2018-05-16 21:28

@luked1uk Yes and no. Yes in terms of getting a smart agency to help you with this, because it’s a HUGE challenge. No in terms of implementation–this is basically your organizational brain, and you really, really don’t want to outsource taht.

richard

2018-05-16 21:29

Woah. I didn’t know outsourcing this stuff was even a thing. I’m a product manager, and I want to literally be present during the user interviews. That’s my lifeblood.

Lou Rosenfeld

2018-05-16 21:29

I will say that the agency model, as we all know, is very likely dying–except for those agencies that specialize. I’m seeing more smart agencies moving into operationalization. Some get acquired. Think CapitalOne acquiring AdaptivePath, and Verizon recently acquiring Moment Design.

hello107

2018-05-16 21:30

Agency models – highly recommend Jules E.’s writeup on State of Digital Nation :ok_hand:

luked1uk

2018-05-16 21:30

Can we change it from User Interview to something more friendly? I feel like when ever I meet users I want it to feel like the opposite of an interview. :smile:

Lou Rosenfeld

2018-05-16 21:30

@luked1uk You’re a smart project manager, because you want to be a part of the research. THat said, I’d be careful–you’ll potentially spread yourself too thinly if your research becomes so multimodal. You really should be thinking about setting up the infrastructure to support the work; IMHO, that’s more critical, as it’ll enable you and your research to scale.

Lou Rosenfeld

2018-05-16 21:30

@hello107 Link please?

Lou Rosenfeld

2018-05-16 21:31

I’m letting my fingers take a little respite while y’all come up with questions/thoughts.

Lou Rosenfeld

2018-05-16 21:32

Go for it @luked1uk

luke

2018-05-16 21:32

We have been harping on about user research sessions should be attended by everyone for years now. What I’ve witnessed as a bigger problem, is that few people use the products they are building. This in itself should be the first step we encourage

luked1uk

2018-05-16 21:32

Ill try to push a new phrase, User Hangout or something :stuck_out_tongue:

luked1uk

2018-05-16 21:33

Lou in an ideal world, ideal company, what does the perfect scenario look like to you? and have you seen it?

hello107

2018-05-16 21:33

Lou part 1 came out in 2016!
https://blog.marvelapp.com/state-of-the-digital-nation-2016/

Part 2 came out 2 days ago:
https://medium.com/swlh/state-of-the-digital-nation-2020-venture-road-22de4377836

Highly highly recommend

Lou Rosenfeld

2018-05-16 21:33

@luke You bet–but let’s take things further a bit and get down the road to a place where it’s not so much an issue of convincing your org that user research is worthwhile. I’m really talking about a stage later on (which is why the talk is called “Beyond User Research”. I argue that we’ve not won the war–just a battle.

Lou Rosenfeld

2018-05-16 21:34

@luked1uk No way. But I’m optimistic that we’re getting there.

Lou Rosenfeld

2018-05-16 21:34

I mean, think of how our research is so clearly the sum of its parts. It’s hard to ignore. Here, let me throw a few slides your way that demonstrate this…

Lou Rosenfeld

2018-05-16 21:35

Lou uploaded IMAGE4 and commented: Some of us are really good at figuring out the what, others the why. SO MUCH BETTER WHEN COMBINED!

luked1uk

2018-05-16 21:36

What are we saying here? its all the same thing? the what and the why?

Lou Rosenfeld

2018-05-16 21:36

Lou uploaded IMAGE5 and commented: Or the obvious complementary aspects of qualitative and quantitive research.

Lou Rosenfeld

2018-05-16 21:36

No, not at all. Actually, they’re currently siloed/separate. I’m saying that they need to be combined.

Lou Rosenfeld

2018-05-16 21:37

Lou uploaded IMAGE6 and commented: Here’s another: some of advocate for users, other for business–and our data supports us. Why not combine?

Lou Rosenfeld

2018-05-16 21:38

Lou uploaded IMAGE7 and commented: Some of us are really good at tracking and measuring what’s known with our products and customers. Others of us are good at finding patterns that suggest the UNKNOWN aspects of how our users and products interact.

Lou Rosenfeld

2018-05-16 21:38

Lou uploaded IMAGE8 and commented: Last one: some of our data is facts and figures. Other data is concepts and ideas. How do we combine them?

luked1uk

2018-05-16 21:38

I do feel like part of being in UX is pulling it all together sometimes and seeing it from all sides

Lou Rosenfeld

2018-05-16 21:39

Yes, but UX represents a specific POV.

Lou Rosenfeld

2018-05-16 21:39

We can’t do this on our own.

Lou Rosenfeld

2018-05-16 21:39

We, like everyone else, come to the table with baggage, and therefore are suspect and should be suspect.

luked1uk

2018-05-16 21:39

very true

Lou Rosenfeld

2018-05-16 21:40

That said, we certainly have much to offer. UX is a synthetic discipline–really a mashup of other disciplines–so we may be more comfortable with a variety of points of view/methods/tools/perspectives than some other, more established disciplines that do some form of user/customer research.

Lou Rosenfeld

2018-05-16 21:41

VIVA LA DIFFERENCE!

luked1uk

2018-05-16 21:41

:smile:

Lou Rosenfeld

2018-05-16 21:42

I see “several people are typing” but no questions/comments. I’m going to drop a bunch more slides on you people if you don’t type over here soon!

richard

2018-05-16 21:42

Lou Forgive my ignorance on this topic. It’s new for me. At first it seemed like you were talking about problems fairly unique to larger organizations where there are lots of silos, maybe less applicable to a 20 person startup. But now as you describe the synthesis of the different kinds of user insight, that seems to be a different thing than the organizational tribal knowledge / siloing issue.

luke

2018-05-16 21:42

Consolidating insights from all areas of the business has been our greatest challenge. From one off surveys, to web agent support chats getting tagged in ZenDesk. Having a consolidated tagging system has been so difficult to coordinate

luke

2018-05-16 21:42

And advice?

richard

2018-05-16 21:42

As this more about synthesis of different classes of knowledge, or of the process of shared knowledge?

gary.bunker

2018-05-16 21:43

What about having a consistent IA for how we describe the knowledge we gain? Terminology, form, structure.

Lou Rosenfeld

2018-05-16 21:43

@richard No need to apologize–it’s new to us all. The synthesis of different classes of knowledge is an organizational/cross-silo pursuit by definition, BECAUSE those classes of knowledge come from different parts of the organization. Parts that don’t know about each other, have different vocabularies and motivations…

luked1uk

2018-05-16 21:43

Print it all out and put it on a wall :smile: take a good look at whats going on

Lou Rosenfeld

2018-05-16 21:44

@gary.bunker If you look closely at what Tomer and team were doing with Polaris, it’s IA all the way down. Huge investment in metadata and content chunking. I just gave a talk in Taipei last week and basically said that the fools who say IA is dead aren’t looking too closely at the challenges associated with operationalizing all these aspects of design and research (among other htings).

luke

2018-05-16 21:45

The vocabularies and motivations have been the main challenges for us. Particularly as the CS team is in Jordan, with English not necessarily a first language

Lou Rosenfeld

2018-05-16 21:45

That makes things even harder, eh?

Lou Rosenfeld

2018-05-16 21:45

No one has a wall that big.

luked1uk

2018-05-16 21:45

lol

crystal

2018-05-16 21:45

I completely agree with all of this. I work for an extremely large organization – silos within silos – and have spent the past 2 years trying just to identify the ux team or the user research team. I’ve found a vast majority of people who do this work don’t have these titles, as you said. I have met others who have tried to get a small group on the same page and share. Do you have any hints, leads, gut feelings about some good avenues to begin exploring to make InsightOps/ResearchOps come to fruition?

Lou Rosenfeld

2018-05-16 21:46

I’ve got a bunch of things in that video/deck. Let me drop a few on you here.

crystal

2018-05-16 21:46

Awesome! I will definitely watch it in its entirety after this!

crystal

2018-05-16 21:47

And share it with others who I work with

Lou Rosenfeld

2018-05-16 21:47

Lou uploaded IMAGE9 and commented: Many of you are probably familiar with Christian Rohrer’s Landscape of User Research Methods.

Lou Rosenfeld

2018-05-16 21:48

It’s by no means perfect–AND it reflects a very HCI-influenced view of research. For example, an analytics person would craft a very different landscape. (And I tried to get Avinash Kaushik, one of the top gurus of analytics, to work with Christian to combine perspectives.)

Lou Rosenfeld

2018-05-16 21:48

But look at those axes, then look at what’s covered in the four quadrants. Think of each method as a blind man.

Lou Rosenfeld

2018-05-16 21:48

Now you can audit your org’s research methodology. Are all your blind men living in one of these quadrants? If so, that’s a problem.

Lou Rosenfeld

2018-05-16 21:49

ANd one you can address–in some cases, by finding other blind men who are already in your organizaiotn.

richard

2018-05-16 21:49

I like that

Lou Rosenfeld

2018-05-16 21:49

Lou uploaded a picture (1) and commented: Here’s another: the concept of cadence.

Lou Rosenfeld

2018-05-16 21:50

If you’re using the Landscape I showed a moment ago to “balance” your research methodology, you might also want to “balance” it over time.

luked1uk

2018-05-16 21:50

good map

Lou Rosenfeld

2018-05-16 21:50

Some research methods look at user behavior on a daily basis–or even more frequently.

Lou Rosenfeld

2018-05-16 21:50

Others are more involved and expensive, like a field study. Can your org balance those things out?

luke

2018-05-16 21:50

Do you have advise for strategy/product people on supporting this better?

Lou Rosenfeld

2018-05-16 21:51

Lou uploaded IMAGE11 and commented: Can your org combine balance and cadence to come up with a framework WHAT research it does and WHEN?

Lou Rosenfeld

2018-05-16 21:52

@luke What I’m showing are frameworks that can be used to pull together diffuse research, researchers, and research perspectives.

Lou Rosenfeld

2018-05-16 21:52

Not that it’s easy, or that I’m providng a solution. I’m not really the right person to solve this problem. I’m just not smart or experienced enough–all I can to is point out the problem and make some broad suggestions as to how to move forward.

crystal

2018-05-16 21:53

Nah, I think that you are once again a bit ahead of your time, which is awesome gets everyone thinking about these things more in depth

Lou Rosenfeld

2018-05-16 21:54

Actually that last slide is incomplete but I can’t get the full version out of keynote right now (as I can’t grab a screenshot of a completed build). It’s in my deck though.

Lou Rosenfeld

2018-05-16 21:54

Thanks @crystal

luke

2018-05-16 21:55

Yep I understand what these are showing. But for these to be effective communication tools there also needs to be a space for the research team to influence as well as collaborate. I wonder if you have examples you have seen of companies that do this well – and perhaps what aspects enabled then to succeed?

luked1uk

2018-05-16 21:55

@crystal I guess everyone is at a different stage in their Org or team with this stuff. I think its a lot about striving for the future and pushing your self to try these new things and implement new techniques.

Lou Rosenfeld

2018-05-16 21:55

We’ve got about five minutes to go. Glad to talk more–also would love to know what people would call this challenge (I’m not wedded to InsightOps).

fmvr26

2018-05-16 21:55

Hello Lou

What is the middle point you think will fit someone from the big data/analytics area within product design? ( I changed careers to product design a while ago but still looking how to use more analytics techniques)

In the other hand I’m currently experimenting with a data-lake like structure for a database of user information (both feedback and research) to then have a central point for analyzing and crafting insights with the hope that it will give a more profound understanding of the users and a better access to all data. *Any thoughts on the matter?*

richard

2018-05-16 21:56

So if the “Ops” monicker is an indication, the thinking here is influenced by the lean movement. Typically that means you accept that there are complex systems nobody can fully wrap their head around, and it encourages interaction amongst parties whose knowledge, inputs and outputs depend on each other, along with feedback between parties.

That evolving system of interaction and continual improvement is in contrast to grand architecture.

Is that a fair representation?

Lou Rosenfeld

2018-05-16 21:56

Trying to digest @fmvr26’s question…

crystal

2018-05-16 21:56

It seems to me to be a lot more than just insights – Collaboration and Strategy

fmvr26

2018-05-16 21:56

sorry if I over-worded it!

Lou Rosenfeld

2018-05-16 21:57

Yes, you’re on the right track. Here’s the holy grail for you and for everyone: how to colocate and, more importantly, CONNECT (in the same repository) those quant and qual data.

Lou Rosenfeld

2018-05-16 21:57

I have some ideas about this, but the problem is that “reports” become the intermediary–reports that are based on quant data.

luked1uk

2018-05-16 21:58

If I can take anything away from this talk today Lou its that I need to talk to more people and get more peoples insight. Its not just my job to understand our users but we can all raise each other up to understand the greater overall idea of our users.

Lou Rosenfeld

2018-05-16 21:58

Once you’re trafficking in reports, you open up a whole vector of risk. Because reports are the lazyman’s approach to understanding the world. We craft them around a question, then–after running the same report again and again–forget what the question was. Or the question loses relevance.

Lou Rosenfeld

2018-05-16 21:58

nicely said, @luked1uk

gary.bunker

2018-05-16 22:00

Thanks Louis, fantastic to spend time with you, awesome insights

Lou Rosenfeld

2018-05-16 22:00

So, glad to hear from y’all: I run a free monthly DesignOps community conference call–if you want an invite, email me. And you all should attend these fine conferences: http://designopssummit.com and http://enterpriseux.net. And buy our books: http://rosenfeldmedia.com/books

hawk

2018-05-16 22:00

And that’s that!

Lou Rosenfeld

2018-05-16 22:00

Thanks everyone; hope to cross paths again.

hawk

2018-05-16 22:00

Thanks so much for your time today Lou – it was an honour to learn from you.

The post Transcript: <em>Ask the UXperts:</em> InsightOps: Getting to synthesis and insight — with Louis Rosenfeld appeared first on UX Mastery.

Customer experiences are increasingly complicated, with multiple channels, touchpoints, contexts, and moving parts, all delivered by fragmented organisations. How can you bring your ideas to life in the face of such complexity? Orchestrating Experiences is a practical guide for designers and everyone struggling to create products and services in complex environments.

What is this book about?

Good designers must thrive in tackling complicated challenges; it is becoming increasingly complex to define and target products and services. This, and a greater focus on creating unique or differentiated experiences, provides us with an opportunity to be a uniting voice for cross-functional teams. To create better experiences, however, means taking on challenges. We must reconsider how we understand customer journeys; reassess our choices in tools, processes and methods; and find ways to work as cross functional groups. Orchestrating Experiences defines this reassessment as:

1. Moving towards a holistic view of complicated journeys that unfold over time, across channels, platforms, locations and people;
2. We all have processes, methods, and frameworks for which we rely on understanding and solving design problems. But as we expand the lens through which we look at the customer experience, we’re realising we need to be agnostic of different design disciplines to deftly evaluate our design challenges and determine the best approaches
3. Re-thinking how we organise ourselves, unifying disparate parts of the organisation. Silos need to be lowered and cross-functional groups united with our own response to the everlasting question: ‘How do we define a shared process for tackling these new challenges together, and reach across the organisation?’

A quick look at the contents provides a clear indication Orchestrating Experiences was written by Chris and Patrick to genuinely impact practices in a way that matters and which lasts:

Part I: A Common Foundation

Looks at the key concepts involved in understanding how experiences can be designed.

Chapter 1: Understanding Channels
Chapter 2: Pinning Down Touchpoints
Chapter 3: Exploring Ecosystems
Chapter 4: Orienting Around Journeys

Part II: Insights and Possibilities

A practical outline of how teams can adopt a customer-centric view, and how they can identify opportunities for improving experiences.

Chapter 5: Mapping Experiences
Chapter 6: Defining Experience Principles
Chapter 7: Identifying Opportunities

Part III: Vision and Action

Techniques and advice for collaboratively generating ideas and crafting visions that unite and inspire action.

Chapter 8: Generating and Evaluating Ideas
Chapter 9: Crafting a Tangible Vision
Chapter 10: Designing the Moment
Chapter 11: Taking Up the Baton

Who are the authors?

Chris Risdon (Twitter @chrisrisdon) is currently director of design for peer-to-peer carsharing service Getaround, but was previously head of design for Capital One Labs. He’s an alumni of the pioneering experience design consultancy Adaptive Path where, as design director he introduced and advanced new methods in design. Chris holds an MFA in design from the Savannah College of Art and Design and is an adjunct professor at the California College of the Arts, teaching interaction design and service design to the next generation of designers.

Patrick Quattlebaum (Twitter: @ptquattlebaum) is a designer, management consultant, and founder at studioPQ. He helps organisations experiment with and adopt collaborative approaches to designing service experiences and the operations that support them. He too hearkens from Adaptive Path, where he was managing director, before moving to become head of service design at Capital One when they acquired the consultancy. He is also a passionate design instructor, having taught thousands of practitioners in North America and Europe. He holds an MS in Information Design and Technology from the Georgia Institute of Technology. You can follow him on Twitter  and @studiopq. Designer, consultant, & teacher.

Who is this book for?

You’ll likely find this book on the shelf beside design books, but it is relevant to anyone involved in defining and creating products or services. In particular, if you’re working in environments with many channels, touchpoints and contexts, and as part of fragmented, siloed organisations attempting to deliver them, this book will equip you and your team to design better experiences together.

It does focus on cross-functional and collaborative teams, and argues strongly for why these are necessary when dealing with complex environments.

The book is pitched at three types of readers:

1. Product and service practitioners of all stripes – people involved in defining strategies for customer experiences, designing or delivering them, or managing the activities involved.
2. Lead roles and aspiring team members wanting to create impactful experiences at scale
3. Executives and managers seeking customer-centred experiences as part of leaner operations

It includes fresh approaches for expanding your toolkit and designing collaboratively. It presents language and models to help teams engage, and concepts with high aims in fostering cross-functional collaboration, building empathy with customers and more effectively taking advantage of customer journeys.

How to make the most of ‘Orchestrating Experiences’

In the foreword, Marc Rettig describes a typical reader’s aspiration: ‘You are buying the book because you’re excited by what it describes, and you aspire to implement these practices’.

What do others think? 

“You’ll blow past your competition, as you shift from shipping discrete functionality to seamless end-to-end experiences.”
—Jared Spool, Maker of Awesomeness and Co-CEO of Center Centre/UIE

“By including workshop plans throughout Orchestrating Experiences, Patrick and Chris give the reader a way to make complex ideas immediately actionable.”
—Jon Kolko, Partner, Modernist Studio

“Hands down the best hands-on guide for service design. Love the in-the-trenches advice and step-by-step detail.”
—Jess McMullin, Principal, Situ Strategy

“Every interaction the customer has around your brand contributes to the story of their experience. This book provides actionable advice to tell a powerful story your customers will love.”
—Katie Dill, Vice President of Design, Lyft

Buy Orchestrating Experiences from Rosenfeld Media.

UX Mastery received a free review copy of this book from Rosenfeld Media but does not receive any commissions from sales. Please support one of our industry’s best publishers by purchasing directly from the Rosenfeld website.

The post Book review: Orchestrating Experiences appeared first on UX Mastery.

Leading an organisation from this role is also a major challenge. It’s hard work implementing a UX focus in a company where none exists. There will be battles against corporate biases, conflicting business needs, and results-driven culture.

In such a difficult position, how can a UXer go about creating a culture of great user experience?

It’s imperative to establish a baseline process, socialise the benefits of great UX, and prepare for the long road ahead.

Above all else, establish a process

When starting a culture of user experience focus, the first step is to establish a clear UX process. 

“UX process is a cornerstone of UX design, it’s a make-it-or-break-it aspect of UX design,” writes veteran UX professional Nick Babich in his blog for Adobe.

“Without a solid UX design process, a designer could be completely moving in the dark. A clear and concise UX process, on the other hand, makes it possible to craft amazing experiences for users.”

Every UX professional should have a favoured baseline process. In fact, you’d expect this to be the first question in any UX interview. Part of any quality answer to this question should be to acknowledge the importance of context. No two companies or products are the same. Processes should differ depending on organisational needs, technology stacks, and delivery speed.

No process is bound to be the perfect fit. An initial process’s existence is more important than its perfection. Install a process to address the largest problems and work to resolve the kinks later.

Whatever process you choose, tailor it to your organisation’s needs. This will help you with the second facet of gaining UX buy-in: socialising UX benefits among stakeholders.

Socialise the benefits of UX among stakeholders

In his Forbes piece Good UX is Good Business, Andrew Kucheriavy, founder and CEO Intechnic, lays out the argument for the business benefits of an improved focus on user experience.

“Good user experience is clearly good for business,” he writes. “ Studies show that companies that invest in UX see a lower cost of customer acquisition, lower support cost, increased customer retention and increased market share.”

While the benefits are clear, you must be able to explain why the UX process is beneficial to your stakeholders. 

UX success hinges on the cooperation and participation of the business as a whole. While you are the engine propelling the car, the whole machine must move forward together. It’s often difficult for internal stakeholders to see the progress and impact of UX focus. By clearly explaining the benefits, you’ll bring your company one step closer to fully embracing a culture of great user experience.

I’ve written previously on how big of a part UX professionals play in facilitating internal communication. We sit at the epicentre of our business. We speak with our business partners to understand project requirements. We work with our technical teams to understand what’s viable, and to support development efforts. We talk with customers to understand their wants, needs, and expectations. An established process allows UX pros to speak about the project pipeline and its direct impact to any stakeholder.

If we are successful as UX professionals, the benefits we add to our organisations should be clear. Our business partners should have a better understanding of our customers’ needs through UX testing. Our technical teams will receive projects that are both practical and well-defined through iteration and revision with our business partners. And, most importantly, our customers receive a product that exceeds their expectations.

Be aggressive in explaining your expected benefits. Take advantage of your team’s rituals and culture to discuss your roll and how your process will benefit specific projects and initiatives. This gives UX pros excellent opportunities to speak on how and why our process benefits the company as a whole, and gain allies in promoting usability throughout the company.

Cindy McCracken, a UX professional with more than 10 years of experience working for the likes of Fidelity Investments, agrees.

“The more you work with co-workers such as support, sales and development and show them the value of UX, the more support you will have within the organisation,” she writes in her article Proven Strategies to Win Over Stakeholders for Your UX Project. “These in-the-trenches supporters will see the value of your work and the successes with customers first hand, and that will go a long way toward impacting workplace culture and filtering up to senior level support of UX.”

There are a few ways UX professionals can quickly integrate themselves into the rhythms of the business.

Attend development standups. Listen for blockers and speak about how your UX process will ease these issues in the future. Pay attention for upcoming work, and ask for inclusion where practical. 

“In planning meetings, be alert for extensive development work planned to go work with interfaces that clearly need to be redesigned,” writes McCracken. “Rather than just let them proceed, bring potential design problems and ideas for improvements to the team.”

Set meetings with your business partners. Work to understand their underlying problems. Explain UX’s role in fixing those issues. Find the low hanging fruit to get some quick wins on the board. 

Take part in retrospectives. Retrospectives are a great platform to show the type of value you can provide for your new team. 

Listen for issues on previous releases. Present your UX process after discussing these issues. Prepare to speak on your process, and how that will affect any issues raised. After your first couple of releases, plan on asking for feedback to adjust your basic process.

Get in front of your customers. Some would argue that it’s not UX unless you’re getting in touch with your users. This is where great UX starts and ends. Working with your clients shows your engaged in their needs. It allows you to talk about projects that are in development. And it allows you to understand wants, needs, and pain points. We take all this back to our business partners to help create a better product.

According to McCracken, a great way to do this early in the game is to test early iterations of projects with your clients.

“[Use] an online first-click test to see if participants go where you expect when asked to perform tasks,” She writes. “You can even ask what people notice first on a page. Better yet, run one study with an image of your current design, and one with an image of the new design to see how user performance compares. If you have a clear winner, it should be easy to get buy-in to improve conversions, which would be a great return on investment.

Prepare for the long road ahead

The road to establishing UX as a team of one can be difficult and lonely at times. Larger teams, for starters, can divide and conquer work.

A team of one, however, does not have that luxury.

As solo teams, it’s important to take some steps to avoid over-extension. With no one to pick up the slack, whiffing on an objective or project can have major consequences. What’s more, the stress of working alone can be intimidating. 

So how can you make life as a solo UXer easier on yourself?

Work with your higher-ups to set reasonable goals and benchmarks. Talk about when you’d like to have processes installed and how you’d like to go about its implementation. Make sure that everyone is clear on mutual expectations and goals. Review your progress and blockers regularly. 

Engage with the larger UX community. One mind rarely surprises itself. In larger teams, UXers have comrades to give feedback. In solo teams, isolation can inhibit creative solutions and stunt professional development. Go to UX meetups. Follow industry leaders on Twitter. Start a blog. Ask and answer questions on Stack Overflow. Join an online UX group like the wonderful UXMastery Community. Whatever you do, get involved with the UX world as a whole in some way. Your conscious and career will thank you.

Conclusion

Working as the solitary UX professional in your organisation is not an easy job, but it can be tremendously rewarding.

In Leah Buley’s The User Experience Team of One: A Research and Survival Guide, she makes the best case I’ve yet seen for the allure of working as a UX team of one. The team of one’s work is as close as one can get to the fundamental values of the UX community as a whole.

“UX is a force for good,” she writes. “[As a team of one,] you help spread the growth of a new and exciting field, one person, team, and company at a time.”

What do you think are the greatest challenges for the solo UXer? Share your thoughts in the comments, or join the conversation in our friendly forums.

The post How to Survive as Your Company’s Solo UXer appeared first on UX Mastery.

What’s important to this discussion, is that I wasn’t a junior anything—I was just a no-prefix practitioner. There were other roles in the company I was working for that were specifically earmarked as senior, however.

So why was that? I’ve always figured that for a consulting agency, referring to a senior-level practitioner and a no-prefix practitioner probably sounded better to a client as we bid on projects – and there’s probably still some truth in that.

I’d like to take this discussion one step further, however, by saying that both practitioners and employers should be aware that these “junior” and “senior” categorisations are fuzzy at best. They don’t always tell the full story of your experience when it comes to expertise and years of experience. Knowing which roles are right for you will help you navigate the job market and pave your own career pathway.

It’s simpler to classify job experience into buckets – but it’s not always so simple

People like categorising others into buckets. This is certainly true for job background and experience, where there is some value to this categorization in the employment sphere. Does a job candidate have enough experience or not? Does this person have a UX brand or not? Is this person a UX leader or a leader in any way?

When all these experience-based considerations get rolled up into the title of a job description, they are often simply classified as “junior” or “mid-level” or “senior” or perhaps “director” or “principal” or (occasionally) “intern”.

UX roles are fuzzy to begin with. And while these titles may be a good place to start, it’s also important to remember that along a number of axes, these titles may always remain fuzzy.

Years of experience

Back before my freelancing days when I was responsible for hiring, I recall candidates who had limited experience yet came across so polished that I couldn’t help but imagine them in a senior-level role. On the other hand, some candidates had years of experience but couldn’t fully explain their background or their understanding of UX. Then when I looked them up online, I found little more than self-created and not particularly impressive social media profiles.

I’ve seen job descriptions that demand 10+ years for a senior-level practitioner, and I’ve seen job descriptions that ascribe only a minimum of 3 years of relevant experience to such a role (with “relevant” being a way to add even more fuzz).

Years of experience could be considered a rough—if not the roughest—way to classify a job description. I’d encourage employers to approach this classification with caution, or at least with an allowance for *very* wide ranges of experience.

Practitioner experience

While years of experience may be a bit fuzzy, it’s certainly fair for job descriptions to ask for certain kinds of experiences. A senior-level hire should already have decent experience—if not expertise—in whatever UX areas are most core to the job. On the other hand, a junior-level hire should have enough basic knowledge to get started, but experience can be limited and expertise is not necessary.

Always remember that as long as you have a good UX base knowledge and demonstrate fit in some functional areas of UX, other areas can be learned. So good employers should prioritise a desire to learn over exact match skillsets.

As a word of caution to employers looking for a UX unicorn —those with the ability to do everything, be it design, research, coding, information architecture, strategy, etc.— These hires are fine for a junior role which lets them sample a little bit of this and a little bit of that. But positions classified as “senior-level” will likely require solid experience and an area of expertise.

Wanting this solid experience and expertise everywhere is not fair to the designated hiring manager (good luck to them!) and not fair to you if you’re a senior-level hire who needs to be everywhere with less opportunity to build expert skills – a topic which I delve deeper into in The UX Careers Handbook.

Leadership

While senior-level positions may be equated with leadership, just what does leadership mean anyway? It could mean that you’re a manager of people—responsible for hiring, employee reviews and overall management of other individuals. Or it could mean that you’re a leader of UX projects and managing UX workflow of others within a particular project. Or perhaps you’re a senior-level practitioner on a project with one or two others—and if it’s a consulting project, perhaps you’re the person who interacts most with the client.

But leadership isn’t only at work, and UX leadership value can be found in thought-leadership (writing, speaking, and posting on social media about UX) as well as UX voluntary leadership, such as running a meetup. While these examples may not represent exact matches of leadership experience with most job descriptions, they can feed into a big bucket definition of leadership seniority.

Finally, with respect to leadership, leadership has to start somewhere, so being a senior-level hire may also mean that you are at least ready for workplace leadership of some kind. As a junior-level hire, on the other hand, you certainly have no need or employer expectation of any kind of leadership, at least for the short term.

What should employers do?

It’s okay to use classifying terms like junior, or senior, or mid-level as a general description, but beware that these can be interpreted by potential candidates along a wide range of expectations.

So keep your funnel wide! Remember that UX-ers are often hard to find, so don’t eliminate good candidates by implying hard and fast rules. And when you do talk with or meet these candidates, even if you’ve set specific criteria, be ready to bend the rules when you see alternative backgrounds that you may not have anticipated.

Look beyond the UX work experience – A passion for UX that extends beyond the workplace is a good indicator of someone who will be passionate about the UX work that they do for you. A desire to continually learn and grow even beyond the job is a good sign that as a new hire they’ll have a passion for learning things that you need them to learn.

What should you do when you’re looking for a job?

Look beyond the classification – If you’re truly just starting out, a junior-level job is probably a good place to start. But if you’ve been in the field a few years, focus on the job description more than the junior/senior/something else marker in the job title.

Be ready to challenge – If you truly believe that your background and experience are a good fit for a position but you don’t quite qualify in some area, such as years of experience, remember that it’s okay to make the case for why you really are someone they want. Just remember that you’ll need to provide solid evidence for your case.

Build up your UX brand now – When an employer looks you up, if you truly end up being liminal to UX seniority, remember that your UX brand—what an employer will find when you are Googled—could be the thing that offers you credibility and the opportunity to take on a position that you really want.

Let’s leave these levels vague

There are no hard and fast definitions for junior, senior, director, principal or anything else. And let’s leave it that way. Loose ideas of what should make a good fit are fine for some general guidance, but both employers and potential hires should do what they can to keep their options open and see what UX adventures may await them!

What strategies have you used to navigate the UX job market? Leave a comment or let us know in the forums.

Just starting out in your UX career? Make sure you consult our ebook: Get Started in UX

The post What Does it Mean to be a Junior or a Senior UX Professional? appeared first on UX Mastery.

On January 3, 2011, I delivered the greatest usability study ever conducted. It was, truly, an incomparable study, with a detailed report that would leave academics everywhere singing its praise from the rooftops. For the first time, my college professors would have been proud of my work. The report was perfect: beautifully typeset in LaTeX, fully hyperlinked, and methodologically reproducible.

Wasted work: page ONE OF TWO on the report’s enlightening table of contents

This world-shattering report was delivered and then…nothing happened. Two years following this report, none of its original findings translated into product action. Anything that did change was the result of subsequent, duplicate efforts.

*   *   *

As a newly-minted researcher, the burning question of “why didn’t that work?” kicked off a six year journey that’s still pressing on. At a higher level, the question is about doing useful, effective work: “what does it take for research to positively influence product and design, and how do I do that?”

There’s no simple answer; it’s a broad interplay of dynamics involving people, processes, and structure. Effective research hinges on organizational ways of working and the team’s desire to learn (spoiler alert: there are times when it just won’t work). It also lies in your own mastery of the research process, technique, and ability to influence the team.

Here we’ll focus on the last pieces, charting the growth of researcher-as-individual contributor from junior, to mid-level, to senior researcher. To make it easier to assess your own progress, we’ll look at it along three axes:

1. [Thinking] Process mastery: ownership of the research process
2. [Execution] Technical competence: technique, method, and output
3. [Impact] Organizational influence: empowerment, alignment, and direction

*   *   *

The research process

A quick baseline: in terms of “doing research” (the defining trait of a researcher) we’re talking about execution, orchestration, or facilitation of the sometimes-linear process of:

1. Figuring out what to learn
2. Deciding how to learn it
3. Uncovering or observing evidence
4. Making sense of what was learned (“synthesis” and “insights”)
5. Deciding how to act on it
6. Ensuring consistent action

The process: laid bare

We use ownership of the process as a proxy for growth and maturity in the role. Your journey begins in the middle and slowly spreads outward to embrace the whole cycle: from basic mechanics and execution toward projects, program level initiatives, and higher-order strategy. It’s an exciting ride.

*   *   *

Junior researcher

A junior researcher starts with prepackaged questions or predefined methods and executes on defined units of work. It’s hard to understand potential outcomes when you don’t have clear experience that relates your execution to specific kinds of output. Each project is a new opportunity to build experience across contexts and methods to learn the types of things you’ll find and how they feed into product.

Junior level ownership

I. Process mastery

At this execution-focused stage, your questions around projects will focus on the nuts and bolts:

1. Who? – Target audience
2. What? – Method
3. When? – When do you want it?

When a product manager says “we should do a usability test” or a designer “needs to talk to customers,” it’s a chance to hone basic skills. Growth comes through experience and reflection, forcing yourself to ask “why do we want to do this?”, “what are we really trying to find out?”, and “is this the right way to get there?”

II. Technical competence

Every interview in and of itself can be a hurdle, and it’s hard to see the forest (project) for the trees (each instance of execution). As a junior level researcher, you must become competent in executing on the basics:

• Recruiting
• Interviewing
• Interview note-taking
• Interview debriefing
• Observation
• Data collection
• Surveying
• User testing
• Simple reporting

Research synthesis outputs are facts, incidents, and simple behavioral insights. You’re ready to move on when these basic pieces can be smartly combined and deployed to ensure a successful project.

III. Organizational influence

Junior researchers strive to empower the organization with insights, and answer on-hand questions. Your influence develops on the strength of that execution, and the sense of judgment that you hone as you learn what your users need and how they do their work:

• Credible reporting
• Fair, honest judgement of design and product
• Interaction-level and usability authority

Failure to have an impact (e.g. aforementioned report on January 3, 2011) is especially instructive: “It’s so clear to me that X is true, and I believe we should do Y. But nobody else sees it — what’s happening?” There’s an outside-in perspective flip that precedes growth, akin to the ideas underlying the practice of service design. It’s not about the great studies that you can do, it’s about finding out what the team needs to push work forward.

*   *   *

Mid-level researcher

By now, you’ve developed a sense for product and design, and can deliver strong, evidence-based recommendations. This speaks to a new level of technical competence (derive meaningful insights and connect them to design or product strategy) as well as influence (be seen as a respected, measured point-of-view and valid source of insight).

Mid-level ownership

I. Process mastery

Now your questions snap a level higher to organize projects and ensure meaningful output:

1. What? – What are you trying to figure out?
2. Why? – Why is this important for us to answer?
3. You recommend Who, What (method), and When

Facility with a range of methods allow you to assess trade-offs and select methods with a reliable sense of outcome. Understanding how projects run, you work backwards from expected outcomes and proactively plan your efforts.

II. Technical competence

From the project-level vantage point, you draw on well-developed basics in new ways and adapt methods to the project at hand. It’s here you take ownership over the project, working as a research partner to push design and product outcome. Mid-level growth in execution also extends basic reporting to employ more robust methods of synthesis and communication:

• Project planning
• Project management
• Structured design and research methods (e.g. mixed-method studies, progressive iterative research while embedded in a team)
• Complex synthesis (e.g., personas, journey mapping, service blueprinting, jobs to be done)

Mid-level research outputs provide rich insights and start to depict the important stories that ground, humanize, and build out meaningful context.

III. Organizational influence

At mid-level, you work within the organization to reframe team questions and incite action with results. You realize that it’s never enough to run a good project and deliver great insights: no matter how “true” or “logical” your findings, they will not promote themselves if you don’t bring the team along:

• Embed and partner with functional teams
• Empower other project teams to do effective research
• Reframe and focus research questions
• Develop a respected point of view on product-level decisions

Understanding what comes out of different research methods, paired with a keen sense of how the organization works, is the next step in ensuring positive product and design impact through research.

*  *  *

The shift from medium to senior level started in late March of 2015 when my consulting team delivered a scientific disaster modeling system for a client. They had tried to redesign an on-premise solution for the cloud, spending millions of dollars and two years shipping a system their customers wouldn’t accept. It wasn’t usable, attempted to do everything but could do nothing well, and it ignored pages of feedback customers felt were essential. Given the messy context of the project, I ran a user-centered discovery and testing program designed to force focus on the project and help pave the way for successful delivery.

During discovery with customer proxies and subject matter experts, we built a set of personas encapsulating the goals, needs, and workflow scenarios of the system’s main users. Within our client and with their top customers we socialized the persona “Daniel” as our primary target: we claimed that if V1 could solve for Daniel’s specific needs (without specifying how), all parties would see real and immediate value from the system. Slowly, with open lines of feedback and iteration, client and customers agreed that Daniel represented their core and most pressing needs. We aligned on a goal: if, by a specified date, our system could support Daniel’s target scenarios, the project’s first phase would be a success.

We tested conceptual and functional prototypes with the client’s customers, learning and iterating until real users could achieve Daniel’s core tasks in the system. The customers, especially non-user buyers, invariably piled on feedback outside the bounds our V1 scope (much like before). With clear alignment on Daniel’s needs, we could address feedback honestly and openly, maintaining focus in development: “Given what you’ve seen so far, do you believe [this input] would help Daniel with [goal] in [target scenario]?” The client and their customers came to trust and respect our team’s ability to act–or not–on their feedback with a clear lens. Phase 1 ended as a success.

*  *  *

Senior researcher

As a senior researcher, you leverage learning in new ways beyond specific project work. Organizations already spin off more data and knowledge (in nice functional silos) than any team can make use of — you look to unlock this knowledge, frame rich stories, and foster broad alignment. This is higher order impact at a ‘research program’ level that must also be balanced with project execution.

Senior-level ownership

I. Process mastery

At senior level, you look to the higher order purpose of every project, request, and activity, often suggesting your own project work based on perceived team needs. Your sphere of awareness shifts from a pure focus on user behavior, needs, and context, and must encompass the organizational reality that supports or stifles meaningful work:

1. Why? – What is our organizational and user impact?
2. You shape, reframe, or reject the entire process accordingly

Owning the edges of the process entails focus on understanding what the organization needs, and ensuring it leads to meaningful action. It’s work that may go far beyond the standard role descriptor of user research: your job is to wrest fruit from the garden of knowledge, but, if it’s not productive, you may need to shovel fertilizer.

II. Technical competence

Moving to the program level, ownership of the research process requires you work in regular partnership with other teams to employ projects strategically. Senior level technical competence is tied tightly to ways of disseminating knowledge, increasing alignment, and ultimately fostering higher order impact than any individual project may achieve:

• Centralizing customer feedback
• Wide audience communication & presentation
• Roadmap planning
• Framing and storytelling
• Workshop facilitation

Beyond insights and rich stories, senior level researcher output is alignment, shared understanding, and direction.

III. Organizational influence

At a senior level, your work introduces new language, shapes the organization’s thinking about users, context, work, and direct organizational inquiry to align with strategic priorities:

• Strategic partner to product and design functions
• Reshape higher-order processes
• Centralize and unlock existing knowledge
• Direct organizational research focus

This includes understanding how to use individual projects to inject structure and clarity into product development and turn learning into broader organizational understanding.

*   *   *

And beyond

As you follow the path of research, a logical extension of the function includes centralizing, framing, exposing, and continually communicating your organization’s point of view on the industry and the user’s needs in context. Empowering teams to learn on their own and ensuring meaningful compassion for users’ context and needs — at organizational scale — is the beginning of “and beyond.”

It does not, however, reduce the need for project-level execution; this will always remain a difficult balance. It may mean a strategic individual contributor role, building out a research function to take on the higher order work, or something else, entirely…

This snapshot is based on personal experience, researching researchers, related reading, and some light extrapolation. If you are a researcher on the journey, at “beyond,” or managing this journey for others, I’d love to hear about your experience.

Special thanks to Abhik Pramanik, Christiana Lackner, Chantal Jandard, Alissa Briggs, and the PlanGrid design team.

The post The researcher’s journey: leveling up as a user researcher appeared first on UX Mastery.

For many designers, culture is a driving factor in choosing a company to work for and build a career. Design culture is more than ping pong tables, free food and a pretty workspace. It’s about providing the tools and an environment to perform at your best.

When evaluating the maturity level of the design culture of an organisation, some questions you might like to ask are:

• Is design positioned within the company as you would expect it to be?
• Are decisions being made without design having a seat at the table?
• Do most of the projects get buy-in from the organisation when they are started by non-design functions?
• Is design being brought in as a last-minute box to check before a product is launched?
• Is the UX team the only advocate for the user, while the rest of the organisation believes that they can just release a product and everyone will buy it?
• Are outside vendors and agencies championed as experts more than the internal team, who are just as capable?
• Are designers scattered throughout the teams, hidden in a dark corner somewhere feasting on scraps whenever the business decides to throw them a bone?

No matter the level of design maturity, each organisation has unique cultural strengths and areas that can be improved. While cultures and their individual fit may vary, these are five qualities to identify a mature design culture.

1. Design is represented at the executive level

Whether you have a Chief Design Officer, or a design level VP, you need to have executive support for design at the highest possible level. This role shows an organisational commitment to design both financially and philosophically. There is no longer a need for the justification of design, it is positioned as a function that’s integral to innovation and future success.

2. A common vocabulary

A mature design culture recognises that design is not the centre of the corporate universe. Having a shared vision and vocabulary among stakeholders with competing priorities and different backgrounds means there is no longer a need to translate design language or business acronyms.

The business manager is worried about profits, the marketing manager about brand, so leave the design lingo behind to clearly communicate solutions in terms universally understood. A common vocabulary allows everyone to be on the same page, speaking the same language.

3. Meaningful projects

One of the main things designers look for in an organisation is the quality of projects they’ll be working on. It doesn’t matter how fun or exciting a project is, if it never sees the light of day it’s considered throw away work.

Everyone wants to work on projects that make a difference. The last thing the world needs is another weather app – there are plenty of good ones already. Mature design cultures aren’t afraid to kill a project from time to time and refocus the learning and efforts into another solution.

4. Design efficiency

Reinventing the wheel is not efficient. It’s also not fun for designers or developers to continually recreate the same elements for every project. Organisations should have efficiencies in place for design activities and collaboration.

Depending on maturity level, these can range from individual elements like such as research method cards, a style guide or a workshop playbook to a full-blown design system comprised of a design language or pattern library with working components. The design activities and processes shouldn’t compete with business processes. Instead, they should be fully integrated into one single process.

5. Talented people

Companies with a more mature culture have less turnover. While culture may attract talent, it’s the talent that keeps the culture evolving. The ideal team would be high-performing, comprised of individuals who continually learn from one other. It’s the best team you’ve ever worked for, one that shares accountability and pushes the other members to grow and succeed.

Culture can’t be forced. It has to come together organically through the continuous evolution of a team as a result of growing in size and experience. The way to cultivate culture is to influence others by putting in the work, building relationships, fostering collaboration, having uncomfortable conversations, making tough decisions, being accountable and influencing others by learning from mistakes and leading by example.

What culture do you look for in a workplace? Let us know in the comments or the forums. 

Catch up on our posts about how to better engage with stakeholders:

• Using A/B Testing to Drive Constructive Conflict with Stakeholders
• Proven Strategies to Win Over Stakeholders for Your UX Project
• What’s the Impact of Investing in UX?
• Ego and Evidence Drive Designs, but Which One is Right?
• Doing Strategy to People

The post Five Qualities of a Mature Design Culture appeared first on UX Mastery.

“Strategy is the conversations between deliverables” – Kristina Halvorson

As consultants, we know there’s a right way to do websites. This belief often comes from a good place: We care about good design. We want to see it work.

But there’s a downside — we can get a touch judgy. We highlight everything that’s wrong with an organisation’s website (chaotic, redundant, and irrelevant), and feel duty-bound to point it all out. After all, that’s what we’re getting paid to do, right?

The risk is that we end up ‘doing strategy’ to our clients. They already know (or at least fear) that their website is a disaster area. Rather than helping our clients, pointing out these flaws tends to leave clients in a crumpled heap. The client may swallow the medicine, but chances are they’ll never want to come near us again. Kristina Halvorson, speaking at CS Forum 2016, had some very simple advice:

“Show clients how they can be even more awesome.”

Better collaboration through not being that guy

How can I apply her advice to my own work? Well, I need to start reframing my advice so I’m presenting opportunities more than naming faults, and stop being so quick off the draw with my opinions. That’s a work in progress, but there is a headstart to being more constructive: changing our language. Also at CS Forum, Hilary Marsh shared two simple phrases that can turn the dynamic around:

• “You’re right”
• “Let me show you how.”

This theme also emerged in Michael Metts’ presentation. “Strategy does not belong to us,” he said. “Instead, our message to clients is, ‘Let me come alongside you, see what you do, and find ways of doing it together’.”

In this vein, Kristina Halvorson suggested we shift our thinking from deliverables with rules to principles. A rule sits outside and judges, externally compelling you to do things that someone else deems right. A principle, by contrast, is internally motivating. It’s developed with the client, and can be as simple as a few guiding lights.

Talking strategy talk

Doing strategy better isn’t just about reframing our interpersonal relationships. It’s also about getting clear on how our work ties into business goals. As a free-roaming consultant/contractor, when I see a client with a clear brief and budget, it’s tempting to just pick up the project and run with it.

The danger here is that our work embeds siloed thinking. Nothing is transformed. Instead, we should interrogate the brief. We need to understand what’s happening on either side of our work.

How can we understand that broader context? The client’s ultimate objectives are unlikely to be ‘have a spectacular website’, or even necessarily ‘meet the needs of the user’. Every objective needs to be tied to a business driver, ratcheting up till we reach the organisation’s reason for existing. 

When it comes to business drivers, we should talk about them in whatever language the client uses. Those of us with technical backgrounds can go to the opposite end and overuse jargon – our jargon. We trot out the ‘XML’ and ‘schema.org’, because that’s smart talk. The same goes for designers, coders, and researchers – it’s easy to slip into our own jargon.

For me, as a trained writer, that means letting go of what I think I know, and not automatically deleting jargon. What if that’s the language that the audience is most comfortable with? If the client thinks in terms of ROI, we talk ROI. We make them feel comfortable and that we ‘get’ them, which builds up trust.

Outputs and incentives

As online communications people, we need to pay close attention to how we’re measured. At CS Forum, Max Johns examined incentives. Are content people’s reporting and reward systems geared around outputs such as blog posts published or reports laid out? By continuing to be measured as manufacturers, are we being excluded from vital conversations on strategy?

Reflecting on how to apply this, I don’t think content people can simply uncouple ourselves from output metrics — at least not straight away. A lot of managers, particularly those in the public service, are too used to a completion paradigm: success is measured by delivering a set of discrete products.

One idea, sparked by Max’s presentation, is that rather than just saying “Yes” to output metrics, we say “Yes, and…”. We produce that content piece, but also ask questions about effectiveness. “How do we know this stuff is working?” “What organisational objectives are we pursuing?”

We can even reframe what we call ourselves. When Rahel Anne Bailie, Chief Knowledge Officer for Scroll, worked for enterprise-level clients, she didn’t always call herself a content strategist. Sometimes, she was “a management consultant specialising in content turnarounds”.

We can be less attached to the divisions and micro-niches in our fields of expertise — and more attuned to the language the client uses at 3.00am, when they’re thinking about the problem.

How do you keep your clients and stakeholders on the same page? Share your tips in the comments, or over in the forums.

The post Doing Strategy to People appeared first on UX Mastery.

To put things into perspective, when we talk ‘strategy’ we’re talking about product strategy.

Amanda’s session was about the importance of having a solid strategy and why it plays such a crucial role in a good user (or customer, or human) experience.

If you didn’t make the session because you didn’t know about it, make sure you join our community to get updates of upcoming sessions. If you have follow up questions for Amanda, you can ask them here.

If you’re interested in seeing what we discussed, or you want to revisit your own questions, here is a full transcript of the chat.

Transcript

The post Transcript: Ask the UXperts: <em>Why Strategy an UX are Inseparable</em> — with Amanda Stockwell appeared first on UX Mastery.