event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. www.captionslive.com.au | [email protected] | 0447 904 255 UX Australia UX Australia 2022 Friday, 26 September 2022 Captioned by: Carmel Downes & Kasey Allen
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 130 think that's really all we care about pretty much. So there you go. A little bit of news. We will have a break. We've got some afternoon Tea, that's the time of day it is, some afternoon tea. When we come back we've got our final keynote of the conference. I'll say some thank yous and a few words and we will wander off after that and have a drink. But for now, tea and coffee, some biscuits, whatever, thank you all very much. (AFTERNOON TEA) STEVE BATY: Come on in and sit down everyone. Welcome. We have one last talk all the way from California, in the USA, a gentleman that I was fortunate enough to meet, I think, 13 years ago now and have followed his work since. He recently took on a senior role with the California government in the USA. He may or may not be able to share some of what he is up to, but please join me in welcoming to the conference Christian Crumlish. Hi, Christian. (APPLAUSE) CHRISTIAN CRUMLISH: Greetings from yesterday. STEVE BATY: I can hear you. CHRISTIAN CRUMLISH: You hear me, yes? STEVE BATY: I can see you, that is even better. Over to you. CHRISTIAN CRUMLISH: I am saying greetings from yesterday. I wanted to just mention that I am coming from the incest radical land of the tribe at the south end of the San Francisco bay estuary right now. It is in the
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 131 bay area of California, as mentioned. Let me get my screen share going. Do you see my screen? It says I am sharing it. But I don't see it. STEVE BATY: Not currently. CHRISTIAN CRUMLISH: Let me start it again, the sharing. We will bend technology to our will. It says I am sharing again, is anybody seeing it? STEVE BATY: No. CHRISTIAN CRUMLISH: It worked when we tested it. We can see it online, I am being told. Can Annabel help me with this? STEVE BATY: We will get it sorted. CHRISTIAN CRUMLISH: Can you see it now? STEVE BATY: Yes, it is coming, I think. Maybe I was pre-emptively optimistic. That happens sometimes with me. Yes. Go, we have it. CHRISTIAN CRUMLISH: OK. Let's get into it. Thanks for having me here. I am happy to be in this totally not awkward situation. STEVE BATY: Hang on, Christian. It disappeared after I said that. We can't see you any longer but we can see your slides. CHRISTIAN CRUMLISH: Do you want to reinvite me and start over, or something?
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 132 STEVE BATY: We don't think it is you. It is here. CHRISTIAN CRUMLISH: That's what my last girlfriend said. STEVE BATY: We will sort it out. One memory I have of Christian is at a conference after party, with him, he brought his ukulele along and he and a group of others were playing a variety of tunes. That was great. Super Bowl was on. We had music. It was good. CHRISTIAN CRUMLISH: That what's IXDA. That was a time. We could just sit around and tell war stories. (LAUGHS) remember that time I still had hair? STEVE BATY: Yep. I do. (LAUGHS) CHRISTIAN CRUMLISH: It seemed like anything was possible back then. STEVE BATY: One minute. CHRISTIAN CRUMLISH: Am I the first person this hasn't worked for? STEVE BATY: For this long, yes. It has been four days of various bits and pieces, but we have had the odd hiccup. CHRISTIAN CRUMLISH: My talk is telescopy. It had two five minute exercises in it that we might not be able to do. STEVE BATY: All good.
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 133 CHRISTIAN CRUMLISH: It can be more theoretical. STEVE BATY: We are getting there, I can see movement. Can you stop sharing your screen, Christian? CHRISTIAN CRUMLISH: Yes, I have stopped. STEVE BATY: There you are. We think we are good now. Try sharing your screen now. CHRISTIAN CRUMLISH: I am about to share my screen. STEVE BATY: Has anyone ever worked in tech support? I have and I have never wanted to again. CHRISTIAN CRUMLISH: Is it still not working? STEVE BATY: What I am doing right now is relaying instructions from across the room, it is still traumatising. CHRISTIAN CRUMLISH: Empathy-building I think. STEVE BATY: I used to answer over 100 phone calls a day for people with tech issues and almost none of it was fun. CHRISTIAN CRUMLISH: There is an expression problem exists between keyboard and chair, I think. STEVE BATY: We have developed an industry to tackle that.
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 134 CHRISTIAN CRUMLISH: What are you seeing now? STEVE BATY: In the room we have a holding screen, so I am not clear. CHRISTIAN CRUMLISH: It looks like it is getting there. STEVE BATY: The issue is just in this room? Do we feel special yet? Is it going to work this time? Christian, go. Welcome. CHRISTIAN CRUMLISH: I will try not to lapse into my default New York super fast talking to make up for time. I will probably try and shorten the speech here and there. Can you give me a sense of the time window we have now, just so I can keep an eye on that and I don't run out? STEVE BATY: You just go. CHRISTIAN CRUMLISH: Product management for US professionals. Working with product managers without losing your mind. Why is a product manager telling me what to do? This is a question I found myself asking myself when I was working at Yahoo, in fact when I was trying to get a job at Yahoo, I was being recruited by someone I had met in this wonderful community, by Aaron Malone to join their team and work on the platform design team at Yahoo as a UED, what they called a unit experience designer, working on the community platform, because online community has always been a passion of mine. I went through this extensive interview process and did design exercise and did a portfolio critique and rounds of interviews and talk to a bunch of product managers and got word from Aaron that they had to pass on me, that she had
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 135 polled for me but one of the product managers vetoed me and said he felt like I was too senior and I wouldn't just colour in the wire frames the way he wanted me to and that is what he was looking for in a designer and they had to stay on good relations with the product managers, so she couldn't really fight him on that because she had to stay cool. They couldn't have someone on the team that the PM wasn't happy with. She said "You might be interested in this other role we have" it was the curator of the design patent library, a librarian job. I was thinking that doesn't sound like me but I considered it and I ended up taking that job and things worked out beautifully for me. It left me scratching my head and wondering who are these product managers and why are they in the picture and why do they seem to be my boss? At Yahoo, I wrote a book with Aaron, my boss at the time, called Designing Social Interfaces, a bucket list with an animal on the cover and we did a revision of that in 2015 that Aaron took the lead on. After I left Yahoo, I went to AOL for a while, out of the frying pan and into the sewer and while I was there, I worked on a team that was trying to raise the bar on both product and UX, at a company not known for its user experience quality, AOL was basically rooted in the 90s and it was still more about UI than about UX. Our team was there to teach people up to date ways of doing things on the Internet and along the way, I found myself playing sometimes UX roles and sometimes a product role, particularly on this product called Patch which is a network of local newspapers across the US all coloured by the same backing and CMS to scale the whole thing. There was a desire to launch user blogs on Patch, we acquired Huffington Post and they had grown its - it had built its content farm off the back of volunteer bloggers and Huffington said Patch should do the same thing and we had a mandate from the CEO to do that and I parachuted into New York for three to four weeks to PM this launch and
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 136 found the team had roughed something out already and it was kind of hackish and quick and rapid and in terms of its - iteration and rushing to this deadline. It felt exhilarating and like I was back in the earlier days of the Internet and when things were more direct and hands on. My boss at the time, Marty, a mentor of mine at Yahoo and recruited with me to work with him at AOL gave me valuable feed back when I came back from New York. He said he had seen while I was doing the product work, that I was energised, lit up, I was in my element and joyful about it. I have always appreciated that reflection he gave me back to tell me something about myself, which is that I had kind of found my wheel house in that case. I left AOL, I was tired of the big tech companies and many layers of bureaucracy and the risk averse decision-making and how it was to ship anything. Many people who worked at Yahoo groups and went through two to three year redesign processes that never shipped, several in a row and had nothing public for their portfolio after six or seven years at Yahoo, very sad. I went to this start-up called CloudOn that made a document editor for the tablet and before there was word on the tabloid or Google Docs trying to solve that problem, it is not interesting to work in the mobile space and the tablet space, in the CLOUD kind of space as a consumer start-up, consumer enterprise we like to say because we want people to take it to work. Ultimately we sold that company to Drop Box, which sounds glamourous but I learned a lot and at CloudOn I felt a lot closer to shipping stuff and making mistakes and moving faster, like the days of the 90s when we made web pages by hand. After Cloud, I went to Drop Box and they told me they didn't need another manager. I had a six month sabbatical and I found my way to a start-up called 7Cups. I helped to build the start-up company, offering free services with a lot of growth and traction to a profitable company. That was breaking even and making money and growing and still offering a free service to 99.9% of users. I
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 137 learned a lot there and went to the entire life cycle of the product CEO relationship, came out the other end, 2019, started consulting with my own company, design and product, mostly helping little or bigger companies build up their product practices, figuring out how to build their teams or solve strategy or operational problems. The pandemic hit and I found myself out there with a little bit less work to do, so I finished writing a book, hence this talk. I started writing another book for leaders calling growing product people. That one is on the backburner, because you can only write so many books at once. And during the pandemic, I joined this large volunteer project at MIT trying to figure out how to do contract tracing digitally in a way that didn't surveil people, that did it all with privacy preserving principles and that effort - ultimately it helped influence indirectly the Google proximity alert system we use now that is not location-based but just based on exposure, risk of exposure. That was an interesting project and while I was there I got word that California was looking for a product manager to help with their COVID web site and I started a contract that lasted a year and a half, working on the COVID site. Running through the end of just last June when we transitioned to site from the office of digital innovation that it built it over to the department of public health, to keep managing it from that point on. We revised this daily dashboard that shows up on the main page on what we call the state dashboard page. We added these lines to give people an indication of the current trends, the key metrics and we refined how the metrics were communicated and lots of things like that. I have some medium posts about that stuff, if you're interested in it? This chart we shipped to show the difference between per cases, hospitalisations and deaths, depending on whether you were vaccinated or not and a version of this chart shows boosted people as well. I quick example of the intersection of product management and UX.
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 138 What does it mean to do product management and government and I will come back and do that talk sometime. An interesting little project, I was when Delta peaked originally, we were asked to come up - add a new chart to show the procession of variants - the COVID variants coming through California. The scientists had two ideas how they wanted to do it. One was showing the succession and the other is an area chart on the right. The area chart is aesthetically pretty and so the executives wanted that. We called it the lava lamp chart and we were worried that it doesn't really communicate as clearly as it could. We used the magic of usability testing to put them in front of people and clearly discover that no, people didn't understand how to read this chart and they did understand how to read the line chart and you could bring that back to leadership. They were happy to go with our decision. It was a product-led process but one that used discovery and research. Just as Steve hinted, I just took a full-time role, I was appointed by the Governor to a role as a product lead for the recently renamed office of data and innovation. I am very excited about that. I hit the ground running with a project that I can't really say too much about until it launches in about a week or so. Except to say that it has to do with reproductive health and I will leave it at that for the moment. I was going to do a little exercise now and as the second step towards the end and dedicate five minutes to it where I would have mumbled and told stories or something like that. I think I want to shorten that time, just given our shenanigans at the beginning. I will talk through it and leave a bit of time for this for people who want to take a stab at it. Firstly, here is the idea. There is something called the empathy map. If you're familiar with a common photo that Dave Gray formed it looks something like this. I think there has been some ongoing questions about whether some of the senses like seeing and hearing are inclusive
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 139 and the metaphors have changed. There is less complicated versions of this empathy map. For the sake of this discussion, you could screen shot this, download it, I can put a link in the chat - I think I can do that without losing everything. That goes to the panellists but maybe someone else can share it? If you can - you can Google empathy map. Grab that and put it on your screen and if you have a way to annotate that, what I would say, the exercise is to do an empathy map review of a product manager, somebody that you work with, the one you work with the most and spend a moment or two trying to put yourself in their shoes. Who are they? What do they need to do? What do they hear, see, think and feel? Their motivations and things that they are afraid of and things like that. Take a minute or two to do that and maybe do that as I move forward in the interests of time. I am interested in people just doing this at all, using this tool that we use in UX commonly for our customers, or end users and applying it to somebody adjacent to you. That is worth doing. It is also nice to think about what you observe, what you perceive to be going on in the head of someone you work with and we will come back to that. Enough on that for the moment. I do want to tell you about product managers now that I have been one for a while, where they are coming from and maybe why they do what they do, why they act the way they act. Before we go too far into the role and the people, we can take a moment to talk about the terminology. Why are we talking about product at all? What do we mean when we say product? When I think of a product, what comes to mind for me is a 20th century industrial packaged object like this, this laundry detergent box, probably made by Proctor and Gamble or some other major corporation. It is the kind of thing that you don't change it very often. You build factories and tool them to crank out products by the thousands that are all more or less exactly the same. If you find
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 140 something you don't like about it, it is a while before you change it. These are self-contained physical objects. Very different from digital software and I think a lot of people are hung up on that fact, the word product conjures up this kind of object, when a digital product is almost always something more like a product service hybrid, something that's providing a service and is still a product in the sense that it has been modified T is a reliable consistent experience, that you can decide is valuable to you and you can adopt it and use it routinely and become a customer or member or subscriber to it. The product metaphor has value and it provides a lens that is helpful and works for the business folks, if nothing else. It can be confusing if you take the metaphor literally or let it smuggle all its ideas into the conversation without unpacking them and asking what does that mean in this context? Product managers like to look at this diagram. Originally shared by Martin Ericsson in an article he wrote. It has its value on the one hand, in that it communicates that product management deals with all these things. It deals with UX and design and the people who are specialists in that. It is obviously in this field, just with engineering and technology and architecture, it need to have involvement in the decisions around those things. To everybody else in the room it represents the business hat, how you are going to make money? What is the plan? How will we grow and are we meeting customers' needs and things like that? We live at the centre of these things. The problem with that is everybody has a then diagram with them at the centre and the other disciplines hovering around the outside. It is not that helpful to everybody else, it is reductive. It is helpful as a check list of topics if nothing else. This diagram has been used and shown so many times that it has spawned a thousand memes and variations and something I have been collecting over time, like my favourite riff on that at the moment is this one. I feel like because I am a
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 141 product manager, I can pick on product managers. Peter has given a talk lately where he marks up this diagram to say firstly, it is not really UX, it is design that is a misnomer, and then to move the word UX to the centre and say it is another name for this thing at the centre of everything that the user experience is the product in a digital product. There is wisdom for that and it explains why UX people feel like they are in the middle of everything and product people feel that way and they don't agree with each other necessarily. Part of the reason why they don't agree with each other is they are not doing exactly the same job, except in some organisations, when they don't have enough people. Even though they are concerned with the same thing and that thing is the user experience and that thing is the product, the user experience design or research or strategist, the product manager or product director or product owner aren't doing the same tasks basically most of the time. Another riff on that original diagram which I think is cool is to take the whole thing and pop it into a larger one and saying your job is staying on the intersection of your product and the customers and their needs. My favourite diagram to talk about what product managers do is this triangle for Joff Redfern who is I think the CEO at Atlassian. While he was at LinkedIn he brought out their mobile app, which is a major effort for them. He likes to break it down differently. He still has, in his general manager role which is busy and operations and leadership and with focused priorities and things like that and the artists' role, they look at this and uses creativity and aesthetics and sees patterns and has insights and things like that. Looks at the larger context. A scientist is empirical, driven by facts and data, checking things out, verifying things, running tests and experiments and learning from that and then growing the knowledge, fitting it back in. You can see the artist and scientist paradigms are not the same as designer and engineer. It is fun to play
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 142 around with some of the ideas. The way Joff explains it is that most people start off in one of the corners, or close to the corner, and sometimes along one of the lines, somewhere between two of these, usually not fully rounded with all three of the qualities fully developed and a product manager to get good, needs to move closer to the centre of the triangle, getting into a smaller triangle, where they are balancing the different inclinations in a healthy way. We all end up staying in the corner of that smaller triangle that we started from. I will always be more of an artist and scientist than a general manager but I think I have tried to grow some of my business leadership skills over the years to get better at that side of things. There is also this paradox about decision-making. Product managers are thought of as people who make decisions, sometimes the decisions you don't want them to make, telling you that you can't do the design or research the way you want them to do it. Not letting something get onto the road map and choosing the requirements or directions you don't agree with, and while there is some truth to that and sometimes product managers are decision-makers who pass things along or impose things on everybody else, but that is not often the case. Product managers generally don't have the authority to make all the decisions, even though it might seem that way to everybody else. They have to persuade people to go along with things and find consensus. The truth is the product managers sit at the centre of the decision-making process and are heavily aware of the critical decisions that need to be made to keep the project moving forward and because of that part of the product manager's job is to identify the decisions and the people who need to make them and cause those decisions to be made. As I have gone from UX to product over time, one of the things I have had to evolve on is become less attached to my preferences, my ideas and what I would like to have on
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 143 the road map even or what I think is the right UX approach, have those ideas available to people when they need them but trust the team, the UX team to do their job. Trust the team to choose direction and make it clear to me when I am giving enough guidelines on what the goals are. Not feel like I have to put my thumb on the scale and force the decisions to be made. There is a lot of little decisions all the time, whether it is OK to ship or not that product managers often have to make because no-one else is making the decisions. When you make decisions all day long, big and small, there is no way to get them all right. You have to get used to this idea that you sometimes have to lead and be sure and take risks and find out that you were wrong, chalk it up, learn a lesson from it and hope you never get it wrong on a critical thing that destroys the whole product. Product managers these days often talk about the lean ethos of build measure learn and the cycle of making something and then seeing how it reforms in the wild and gathering data and interpreting that to learn things and coming up with new ideas and building based on the new ideas and perpetually evolving it. It is a cool idea. It has value. You can argue about where you should start in the cycle. A UX person would say "Why don't we learn stuff first and then build"? But the truth is, wherever you start, if it is a cycle, you are going around and around. It is also something that bothers UX people sometimes that there isn't really a lot of time dedicated to learning. There is lip service to that but the truth is it is often a much more build-focus cycle. There is a bit of measuring and less learning and a lot of focus on shipping more stuff. That could be threatening to folks. There is an ethos that makes sense, to be fair. Product managers have to wrangle engineers and bring them on board, synthesise their points of view, maybe sure they are happy with the direction and productive and taking responsibility for what their end results are, being accountable for what happens. UX folks are used to
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 144 working with engineers. We all know, when we are in a UX role, whatever we design is dependent on who builds it, for what is going to happen and then it is a partnership. UX people have the ability to walk away, they - I shouldn't say walk away but wash their hands. They say I made this design, put my best forward and I advocated for keeping it pixel perfect or making it responsible or building it in a certain way, they weren't able to do it right, I am disappointed but I did my part. Product managers don't get to say that. They have to be responsible for what happens and accountable for it. You can't say "The engineers didn't build it the way they should have" you have to say "Why did I screw up and not enable the engineers to do it right?" That is a hard job. Product managers are also responsible for making sure that the project stays on point. If you ever have a team, you can go down rat holes easily and have interesting discussions that everybody jumps on that are not the most important topic of the meeting and there is just a lot of choices about what to do all the time. There is an abundance of good ideas all the time. The trick of all the work we do is you can't do every good idea you have. You have to choose the ones that are the most valuable to try or learn from, or to pursue your end, at the price of not doing the second, third and fourth best idea and later on you find out that those ideas were actually the best idea and you chose wrong but you have to make those choices all the time. Product managers are often the ones making - focusing the team's attention on deciding what to do and making sure it all ladders up to some sort of product strategy, objectives and company strategies. Something that makes sense and gives coherence to all these decisions and choices that we make. As hinted before, the product manager isn't anybody's boss. They may feel like they are a boss and I am sure sometimes they are, but they don't do most peoples' annual report. The engineers report to an
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 145 engineering manager and the UX people likewise report into some sort of lead of their specialty. I have worked at organisations where UX people have a boss who is a product manager or director or something. The product manager on the team is typically not the boss of the other people on the team, even if they act that way sometimes. Their job is to persuade people to get on board and find out what the focus should be and get everybody aligned with that. That is true with stakeholders, with bosses and clients and things. There is that empathy map again. That is a bit of the devil there, looking at what do product managers do and where they come from and what kinds of responsibilities do they carry? I want to go over what are the most common complaints from UX people about their product managers, or about the challenges working with them? I have had these conversations with enough teams, that these complaints are not always from the UX people. The complaints come from the product managers as well, sometimes phrased in different ways. I have tried to synthesise that a bit too. A common thing you hear from the UX team is the old complaint of designers, that they are brought into too late or we used to complain about this - that the idea has been decided already and you are just asking me to colour it in and make it pretty. It is too late to do research because we have already decided on what our solution is, things like that. You find out about product direction when it has already been decided and you are not being included, so you are not in the room anymore or upstream enough and things like that. Related ideas, figuring out the requirements, that can be difficult. There can be different ideas about what a requirement is and how and where it comes from? How it gets validated and who owns the list of requirements and what that means? A product manager can use the requirements as a check list to decide whether there is something
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 146 acceptable to ship or not and it can give the requirements as a straight jacket rather than letting their requirements be derived from research and figuring out the jobs to be done or the user stories and compress it into the requirements. Design and research is often presented to product people and then it feels - it can feel to the UX team like it is falling on deaf ears, like there is a yeah, yeah, yeah but no actual influence on the direction. This complaint is one of the ones that comes from both sides, in different wordings. The product people complain that they have trouble understanding sometimes the jargon and the way that design and researchers could be communicated and the discussion is not presented in the most consumable way for those folks. Whoever is to blame, any communication failures mean you are no longer to connect that way and have the influence on the product that one would hope. The prioritisation that I have been talking about over and over again is not often done in a way that is collaborative or transparent but it is handed down. The team is told that the CEO wants this, or the sales people want this or the product managers decided that our priorities for this quarter are X, Y and Z rather than some sort of clear reason for those things or some rear process that everybody understands and can relate to. A general almost a generic problem that manifests over and over again in different specifics is that we haven't collectively as professions and people working in this field, had enough of these conversations about what the different roles are, about what is a product manager supposed to do? What is our definition of product management here at our company, in our enterprise or at our group and what is the role of the UX designers or strategists? And what you find is that people are bringing some assumptions from their training, from their previous teams, what they have picked up on the street and if these things aren't surfaced and
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 147 discussed the little barbs that keep getting in the way, the unspoken assumptions are carried into the room. If I have an assumption about your job and what you do and it is not the same thing that you think you do, I will probably say things that are offensive to you from time to time as I mischaracterise your job or relegate it to a role that you don't think is fair or accurate. A lot of the hurt feelings and stepped on toes come from this ignorance and a lack of awareness that there are misunderstandings here. I see that over and again. The other thing is that there is not necessarily enough process inside a company to help work out these problems and I do understand - I was reading something online the other day saying people are tired of having to work on the work all the time. Why do we have to keep defining the damn thing and arguing about the roles, why can't we get on with it and do our jobs? I understand that when you are on a team who has worked through that stuff or has a shared understanding of what to do, you can get on with it and it is great. We also have to be honest. We are not black Smiths doing a trade that hasn't changed for hundreds of years - and that is probably not true, blacksmiths will probably come after me now. Making stuff on the Internet is younger than me. It keeps changing, the job titles keep changing, the multidisciplinary teams change, the approach, terminology and everything keeps changing. It will keep changing. We are at the dawn of this thing and early days. There is no reason to think we should have it all figured out or assume everyone else knows how to do it and our team is the only one that doesn't. If our bosses say we are a product team now, you are not a UX designer, they owe it to say what that means to them. Is that a new name for my job and that is risk keeping up with terminology changes? If I am a product designer is that different from being a UX designer? Is UX not important anymore, or is it just we don't say digital anymore but we say product
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 148 because you are not designing airplanes and you are not designing ad campaigns, you are designing digital products. If that is the answer, fine, it probably doesn't change your job that much. If you say we use the product management techniques, they owe it to the team to work through a process where the team can define it for themselves or explain what that means. You may have other points that fit into this list, or you may have none, but I suspect a lot of people will recognise these problems. I say in my consulting that they come up over and over again. That is the bummer part of the conversation. As I have been - my book has come out and I have spoken at conferences and done workshops. I was in Lisbon a little while ago and I heard from people in the audience, I have noticed a certain amount of pain, trauma, anxiety, frustration. This is understandable. If UX has a seat at the table and has spent a decade or more trying to make a case for why it is important and needs to be involved strategically in the making of digital products, software or whatever you call it and suddenly there is an upstart coming up from the side, acting like the boss, claiming that it knows UX and UX is one part of what it does and taking the seat at the table that we thought we had or shoving us to the side, then it is understandable to have anxiety about that and worry. I have been around long enough to have been through this cycle more than once. I can remember when self-identified information architects were uncomfortable, that UX or interaction design was coming along as a dynamic, more popular frame for the kind of work that we were all doing and it claimed to include IA as part of what it does, but used that to mean the menu system for your web site or the structuring of your files or something like that. A reduced and stunted version of IA. You say the UX people don't understand IA, they have turned it into one chapter in their boot camp. I have heard the same complaints from UX people, that UX is just a check box in the
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 149 product person's list, it is not real or something that they understand. That is the part that is frustrating but it is all true. This is where we take a turn and get more positive. The good news is these are solvable problems. You are problem solvers, UX is a problem-solving craft. If you have gotten - if you are in a UX career, you are developing what I call super powers, skills that can be applied not just to making great software experiences but also to solving the how to work together problem, which is an experience design challenge if you think about it. What are some of the super powers? UX people have a toolkit of creative problem solving problems - problem solving techniques. Those problem solving techniques have been packaged up and sold to business leaders as design thinking. We know what we do and we look at why doesn't anybody sign up? What do people in this space need to solve their problems? We define problems, we understand them and break them down and we design solutions to those problems, so that is a technique that we can bring to other problems, besides what should an interface be. There is the ability to visualise things, communicate aesthetically, to find the right words to persuade or frame an idea. Those are UX super powers. The able to go out and find out what the users know and need and want and to take different signals. Qualitative research, academic research, comparative research and data and put that together into a narrative and moving through a system and come up with a model of that system or a way of talking about, these are the things UX people have to do and that are valuable, in terms of looking at complex problems and bringing something to the table in the product frames. The information architecture and content strategy, disciplines that have to do with structuring information and concepts. It has a direct application to the end result, architectures are the things we build and the content strategy and the design methods to view them with the meaning that they need.
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 150 The same skills can be used to think about the structure of the work and the right language to use in working with each other and things like that. There is this ability to grapple with data that goes beyond blindly or opaquely taking data and feeding it back into the system to try and get a number to go higher. There is that prioritisation space which I have touched on a couple of times where product managers are obsessed with figuring out priorities all the time and UX people have a series of techniques for prioritising. We all know about using stickies and pulling together workshops to try and get people into alignment and decide what direction to go in or what to do strategically, so there is a lot to offer to the problems of figuring out what to focus on. Also just my friend Andrew Hinton wrote a large interesting book on how context applies to UX design. It is probably not for everybody but it is fascinating, it is that deep information architecture, not about what is on the pull down menu. It is more about how do we understand the information spaces that we move through and how are the concepts related to each other and what is the big picture? That ability that UX people have to take all these parts, synthesise them and say this is the context we are in and that determines what we should do. Our super powers that can be applied to the problems of why is it hard to work together or frustrating to figure out where UX begins and product ends? There is typically turf problems. I put a question up on LinkedIn a while back that asked people where they draw the line between product and UX? More than half the peoples' answer was "There is no line". There is a grey area, where they blend together. That was a sophisticated answer and probably better than saying "Here is the line, this is UX and this is product". I give points to anybody who said there is no strict line and there is an overlap or grey area. At the same time, I asked the question partly because you still have to have some lines in the work that
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 151 you do, or else you step on each others' toes. Who is doing the research, who is doing the wire frame? Who is writing the copy? Or whatever the tasks are. As a consultant, I have the luxury of looking across a lot of teams and seeing different ways that teams are organised, different problems that teams have and commonalities. Almost everybody believes that everybody else has it figured out better than they do and they are struggling with these problems, when it is the opposite almost, almost everybody has these problems and very few people have it figured out. Mostly they have figured it out for their team and you have to do it all over again when you have a new team or when your team changes. I would advocate about the hidden assumptions, explicitly negotiating, not having passive aggressive jockeying for position but realising if we don't agree on things, let's get that out in the open, let's figure out if we agree or not and if our bosses agree. Let's agree that there is things we all care about but we don't have the final decision on. You can be involved in a topic but you may not be the person who gets to decide that thing. That may be a UX person saying "I care what you think product person but this is a decision decision and that is my decision" and vice versa. You have to have those discussions to figure out if you agree on whose decision it is. You have to have a system that your bosses have told you that defines that. You need to get the assumptions out in the open and figure out if you agree on them or not. If you disagree, you have to work through them. I often do a task sorting exercise with teams, where I have them write a bunch of tasks that they know the team has to do on stickies and put them on the board and sort them into what role does which task. It is usually not that controversial. A lot of the tasks it is clear who does what. The list of things that people disagree on and it is usually a small number of the stickies, five or 10, maybe 12 or 15 at most. Often you can
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 152 consolidate them into a couple of key points. That is interesting to do. Firstly, you immediately see 80% or more of the stuff is not controversial and there is no problem and you can let that stuff keep being the way it is. Then the things you don't agree on, the places where you are still disagreeing with each other, that is where the hard work is, the awkward conversation has to happen, the slightly hurtful assumption is brought to the surface so you can figure out what you all think and you can work through how you think things should work. In the end you won't agree on everything. I have rarely been involved in a negotiation that came out where everybody shakes hands and agrees. There is give and take, some disagreement, you temporarily accept things you don't like and you make note you didn't agree and you check later to see if it worked that way. If we are agile, we should routinely iterate how it worked. If there is anything I like about agile, it is not a great way to avoid waterfall and keep changing your plans but it is a way to have a team continually reflect on how it works and what worked and what didn't and change the way you work together to improve that. Sometimes you can't get that. It is not always true that you will be able to work it out in a room together, even with a consultant facilitating the conversation. If you can't resolve it, you go to your bosses and have them sort it out. The research or discovery area is both the most frustrating for many people and potentially the most fruitful area of collaboration between product and UX. I see frustration usually in UX people, user research complain about product managers having an impoverished idea of research, resorting to sending surveys out or getting outside the building and walking down to a coffee shop to show an app to people at the bar, or calling up customers every week or something like that. They are all possibly good things to do, except maybe the survey. At the same
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 153 time, product people don't always appreciate user research, sometimes feels like it takes too long or it is too qualitative for their liking or they don't know how to act on the recommendations or they come at an inconvenient time. There is potential for being at cross-purposes on research which is an enormous waste of opportunity and usually a bad sign too. It is important to work through that together and compromise as necessary. If you are a researcher and you think surveys aren't the answer but your product managers seems attach today that idea of using one, at least help them review the questions and help it be a better survey and occasionally offer alternative methods to get at the problems you are trying it answer, like you would with any kind of solution handed to you on a plate, you would try and back it up and say "Can we talk about what this is supposed to solve?" And you can offer other ways to achieve those goals. Not everybody wants to hear that but you could offer that to help them do what they want to do better rather than telling them they should do it the way you want to do it, if that makes sense? It is worth working through that because if you can create an alliance where you piggyback on each other - if they are going to do a survey, help them write better questions and get some of your stuff in there. Ask them about their current research goals and ask them if you can help them user testing you are about to do, the focus group or the research, whatever it was. If you can build a research plan together, using your user research skills and offering that as an asset to help focus the product discovery and if the product person isn't defensive about that, instead of having a competing research product, they have an ally in super powering their research. That ability that a lot of us have developed in user experience and information architecture of coming up with a diagram to explain relationships, concepts, not just always literal, apps and user flows but
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 154 things that show domain models or user journeys or conceptual relationships between moving parts in a system. Those kinds of visualisations are valuable artefacts for a team to rally around, debate the finer points on, discover patterns and to use as a focus. I will tell you that I have been an information architect, a UX designer, a product leader and director. In all those roles I want those diagrams. In some of those roles I have made them. I am capable of making diagrams but there are a lot of better diagram makers than me. If I am a product person and the UX person brings me a diagram, that is a gift. If they have given me a picture, or drafting me a picture, that is valuable. That kind of artefact is something that is potentially a house warming gift to the product person saying "Here, I made something for you". I mentioned that you can be fixated on data. I like to say - I am one of these people who doesn't believe in data-driven design. I don't let data drive but I like data-informed design. Now I have been a product person and consumed tonnes of data, I can't imagine doing this kind of work without good data. There is a diagram on the left from my mental health start-up that shows a conversion rate that started around 1% and through experimentation and ups and downs over the course of a year, got to above 1.5% which is more than a 50% increase. The little gains added up. That is how we got to break even. Not all data is product analytics. There is customer satisfaction, there is all kinds of data that product teams are using to steer by and that will be in the picture no matter what. We just don't want it to be taken without any context or misinterpreted. People project reasons for data and assume that they are true. Design research exercise into the picture and says "We think we know what is going on here, let's see if that is right and our hypotheses are true about why people aren't converting or signing up and why they
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 155 are interested in this feature suddenly". The third part of that triangle is experiments where you take the hypotheses and use them to try things out and then there is a partnership on discovering ideas and then building things to try and learn whether they are true and taking new information. The illustration here is called an experiment pipeline used to organise hypotheses and experiments to test and rank them. Just like features, you can't do every experiment you can think of. You have to prioritise the ones you have time for and your engineers have time to build and you have time to monitor and things like that. I love them but I don't work for them. Prioritisation. We are back to that again. If you are in UX, product managers are often figuring out how to do the important things that aren't urgent, so sorting things out so they don't get neglected and we aren't always reacting to whatever is on fire. Trying to compare impact versus effort and the magic squares or in a more of an approach - a version of this recently on the COVID site we included this feature called "Page feedback" which is a simple thing which says "Do you find what you are looking for?" And allows a person to make a comment. We wanted to add it to the Californian design system so the State Government web sites can adopt this widget and add it to their site. They go from no feedback an the occasional person who finds the email address to feedback on every page to help you decide are we using the right words on this page so people can find it or are we answering their questions? On the COVID side, people wanted to know about variants and maths and we told them to develop more content or change it to make it easy to find. It is one thing to make a tool for yourself. It is another to make it so other teams can use it. We had a backlog of features that would make it button down for more people. The impact of this feature of high, medium and low, with the effort behind medium and low. This feature would have a bad impact
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 156 and still be difficult to do. The grey ones were a system thing rather than user things. We sorted them into high impact, low effort, do and medium impact and effort and probably do and then the stuff that is high effort and both. Maybe not get around to that stuff. Do these things and get onto this. Maybe this later and definitely not this. I did this - I am a product manager and I did this quick and dirty road map exercise with the team to figure out how to get this ready to ship. If you take a step back and look at this, this looks like what UX people do. Our UX designer helped to facilitate a lot of this. We kind of did it together. That is the way it can be. Bottom line on all this is that you can use your super powers on your work environment, on how you design the work, how you work out your relationships with the product managers in your life. That means thinking about how - if there was a customer who wasn't behaving the way you hoped they would, you could say they should know UX better or understand our product better and know the terminology we use. I think for UX professionals, we know that won't solve the problem, wishing that they would be like us or already know the things that we know. If you think about your adjacent colleagues in the next discipline over, the same way, you could find instead of saying it is annoying they don't know UX very well or they use this jargon that is weird and they don't understand my jargon, you could say what if they were a customer you were hoping to sell something to? You would probably try and understand what their problems are and how you can solve them. We in the UX team have to do it all. We are the empathy people. We claim we are good at understanding what other people need and feel and want. That shouldn't be true just for customers, it should be true for all human beings that we work with. It is part of our ethos in UX to meet those other people more than halfway. We might say they should meet us
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 157 in the middle or we say come all the way but truth is, usually you have to go almost all the way to the other person if it is important for you to make it work. When I talk to product managers, I tell them that, except I use product jargon and tell them about working with them is like a product and they need to get the consumer to hire them more, to do the jobs to be done and all that stuff. It is the same idea, trust me. You learn the way people work and you figure out what is working or not and you iterate on that. We tried something and that wasn't the solution. Try something else. The problem solving skills are applicable to these problems every bit as much as like the cracking the nut of making your business successful or your policy work or something like that. I have lost track of time. I hope I am not delaying the party. If there is enough time, I would revisit the empathy map and grab a copy of it or scribble on the same line or don't do the exercise but listen to me talk and think about it or whatever. To come back and having listened to me talk for a while about where product managers come from and how we relate to them, go back and answer the questions about who they are? What do they need to do and what are their pains? The point of an exercise like this, my first point is to put yourself in their shoes and just stab at it and discover what you find you think about those folks you work with because you may not have over articulated that to yourself, the point of doing it again after a while, is to notice whether anything has changed. Maybe you were right on the same things and nothing they said has changed the way you think about product managers. That would be interesting and maybe disappointing that I didn't tell you anything you didn't know but it would be interesting. Having thought about this, having listened to me, maybe you would change something about your understanding of where their pains are and what they are looking for and what they are feeling and that also ought to be interesting and give you
event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 158 some room to think and to target those people you work with as you would a user whose needs you were trying to meet. I think I have reached the end at this point. I will say thank you. If there is time we could do questions? (APPLAUSE) STEVE BATY: Christian, thank you. I think we will leave it rather than ask questions at 5 o'clock on a Friday afternoon. Is it midnight for you? CHRISTIAN CRUMLISH: It is just after midnight. I have finally entered Friday. STEVE BATY: Thank you, we wish you all the best. Have a good night, what is left of it. Thank you. (APPLAUSE) That brings us to the end of UX Australia for 2022. I hope you will give me a couple of moments and indulge me before we go and have some drinks. I wanted to begin by thanking the crew, the volunteers who have been helping out over the last few days. A big thank you to Annabel and Jasmine who have done a fantastic job getting us to this point and running a hybrid event in person and online over last few days. Firstly, join me in thanking them all. (APPLAUSE) I would also like to thank all of the speakers who have presented over the last two days. Our conference really is some idiot on a stage introducing some brilliant other people, let's be clear who the idiot is in that scenario. And it is really the value comes from those speakers, people like Christian, people like Tim, Lara and Corey, sort of anchoring the day but everyone who gets up on this stage joins us online and shares the wisdom of their years of experience, it's a wonderful short cut for the rest of us. It puts us ahead in leaps and bounds, saves us some troubles, avoids our own trauma, it really is an invaluable service that they are
uxaustralia
root_recruit
ashapiro
cyberagentdevelopers
hiranotomoki
otanet
masayofff
moshimoshiyuki
ncdc
yuichi_hara7
minamitary
thebogheart
addyosmani
kneath
jmmastey
matthewcrist
andyhume
thoeni
colly
ufuk
orderedlist
moore
jeffersonlam
trishagee
