Working with UX in Product by Rightmove Consumer Product Lead
•Als PPTX, PDF herunterladen•
2 gefällt mir•4,068 views
Product Management Event at #ProductCon London about Working with UX in Product by Consumer Product Lead at Rightmove, Melanie McKay.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Working with UX in Product by Rightmove Consumer Product Lead
Ähnlich wie Working with UX in Product by Rightmove Consumer Product Lead (20)
Mehr von Product School
Mehr von Product School (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Working with UX in Product by Rightmove Consumer Product Lead
- 1. www.productschool.com Working with UX in Product by Rightmove Consumer Product Lead
- 2. FREE INVITE Join 35,000+ Product Managers on
- 3. COURSES Product Management Learn the skills you need to land a product manager job
- 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. COURSES Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. COURSES Digital Marketing for Managers Learn how to acquire more users and convert them into clients
- 7. COURSES UX Design for Managers Gain a deeper understanding of your users and deliver an exceptional end-to-end experience
- 8. COURSES Product Leadership for Managers For experienced Product Managers looking to gain strategic skills needed for top leadership roles
- 9. COURSES Corporate Training Level up your team’s product management skills
- 11. Working with UX
- 12. Hello
- 13. Respect
- 14. Wait, what do I mean by UX?
- 15. https://www.usertesting.com/blog/2015/09/16/what-is-ux-design-15-user-experience-experts-weigh-in/ UX design is a commitment to building products with the customer in mind (Marieke McCloskey) UX design is the art and science of generating positive emotions through product interactions (Tomer Sharon) UX design is the process of designing a solution that considers all the needs of the user (Brent Summers)
- 16. But it’s not just about design (Or at least in the traditional sense)
- 17. So if it’s a whole discipline, why should you be thinking about it?
- 20. Some tools 1-2-3
- 21. Who are your users?
- 23. Who sets the bar?
- 25. Key takeaways ● Know your users (and remember, you are not a user) ● Look at their experience beyond your product ● Understand the expectations ● Test and learn ● Respect
- 26. www.productschool.com Part-time Product Management, Coding, Data Analytics, Digital Marketing, UX Design and Product Leadership courses in San Francisco, Silicon Valley, New York, Santa Monica, Los Angeles, Austin, Boston, Boulder, Chicago, Denver, Orange County, Seattle, Bellevue, Washington DC, Toronto, London and Online
Hinweis der Redaktion
- Hello! My name is Melanie McKay and I’m the Consumer Product Lead at Rightmove. I’ve been working there for about 18 months but have worked in Product since 2005. If you don’t know what Rightmove does, we’re the number property portal in the UK, with well over 1Million properties, over 29 million searches performed a day, and well over 208 billion minutes spent on our platforms per year. Here to talk about UX in Product. I did a longer talk last year at one of the Product School weekly events and both then and now had to stop and think about what this title really meant, but also what people might expect. I did some research both times and found two areas - 1. How to consider UX when developing Products, and 2. How to work well with internal UX teams. I’m going to try and cover both by coming at both problems from the same starting point, one of respect.
- Whether you have an in house team, or the User Experience side of Product Development falls to you as a Product Manager because of the capacity of your team/company, you still must have respect for UX.
- On that - not sure if it’s a side note or the elephant in the room - I’ve always struggled to find one view of what UX really is, or what it means. I should quickly state/remind you al - I’m not a UX expert. I’ve worked in Product Management for 13 years and that is where my experience lies, but I think it’s impossible to be a good Product Person without considering UX.
- UX design is a commitment to building products with the customer in mind (Marieke McCloskey) UX design is the art and science of generating positive emotions through product interactions (Tomer Sharon) UX design is the process of designing a solution that considers all the needs of the user (Brent Summers)
- When you shorten something to an acronym it can lose it’s meaning. That is definitely true of UX. Often when people talk about UX, they are quite often talking about UX design. And those previous definitions work well to adhere to that. There is much more to practice of User Experience, design is one aspect of it. UX encompases user behaviours, the interface design, user needs, information architecture, content, research… It’s a huge discipline in itself. For the sake of not derailing this talk too far, let’s say this: When we are talking about UX today we are talking about understanding your users, which includes who they actually are, understanding what they are trying to achieve, their experiences with your products and the problems you’re trying to solve.
- So, why think about User Experience? Quite simply, your product is going to be used by someone, so of course you should be thinking about the experience those users have with it. Back from that elephant sized side note. Where does it all fit in? Why am I saying that to be a good product manager you must be thinking about UX?
- You’ll likely all be familiar with this diagram. Personally I’ve used it often to aid in explanations of my job, whether it’s to a new team that doesn’t know why I’ve turned up or to an auntie at a family party who doesn’t know what I do. I like it as a diagram, but I’m also wary that I think it does two things - 1. It pigeon holes people/teams 2. It puts Product at the centre and that can be used by people to leverage its importance in a way I don’t always think is healthy. So let’s change the words. Take the teams away, and focus on what’s happening there instead.
- Understanding our users, understanding what’s possible, understanding the business goals, and understanding our problems and opportunities. Business goals - as a business, what are the aims? What are the priorities? What are the KPIs? Who are the key stakeholders? Who are the subject matter experts? How has the business performed? What are you, as a business, working towards? By removing ‘business’ from that circle and reminding us what we are looking at, we may even stop referring to an entire collection of SMEs as ‘the business’ like our colleagues are somehow different to us. But that’s for a different day. Next up, what’s possible? Starting point - what does our technology allow us to do? Are we limited by rigid release cycles? are we stuck on a monolithic code base? Are we under capacity in terms of numbers? What can our technology do? Users we’ll obviously go to in more detail but for now let’s say you need to know everything you can about them, who are they? What do they do? How do they do it? Why do they use your product? How do they use your product? What drives them? What turns them off? And then the balance of all this, what are the key problems and opportunities? Gosh, I made this one sound far more simple than it is. Balancing everything, understanding what good looks like, and how we’ll know if we’ve achieved enough. Not easy. Plus the work doesn’t stop here, but we’ll get on to that later. Hopefully the key thing here that you get or the key thing I’m trying to get across is that all of these parts are important in Product development. If you try and build a product but you don’t understand what’s possible, or what your technology allows, you’re probably going to go wrong. I’m sure many of us are used to hearing things like ‘I just have this small request’ and then you have spend some time explaining why it is isn’t so easy to just allow users to build their own home screens, or whatever you might be asked. And you could sit in a room and come up with a whole loads of problems and solutions to solve based just on what you know about users, and what your tech allows you to do, but if you haven’t considered the business goals, it’ll be luck that means you’ve achieved what you as a business have set out to achieve. All these parts are equally as important, and dropping any, or not paying any enough respect will lead to poorer development down the line.
- So now I want to talk about 3 key things that you should do to help you know the answers to the questions. Let me be clear, there’s a lot more you can do, and if you’re lucky enough to have an in house UX team, then for sure they’ll be doing all this and a lot more. But it’s a good starting point, plus even if your UX team are doing what I’m about to go through, the most important thing is that you also understand the outputs and the information as well, not that its left for someone else to figure out.
- So, knowing your users. At Transport for London (my last company) we were looking at creating a content strategy and we started with who are our users? We used up a few packets of post it notes (who doesn’t love a post it note). And we wrote down everything we could think of. Don’t worry about the groups, if one sounds a lot like another, if one is a sub category, if you’re not sure how much they use your product, or which is the most important. Ignore that and get writing. Cover the walls, the board, the table, whatever just get them all out. Just by covering one wall at TfL I had a much better view of just how many people we were talking about. The next thing I’d do is to start to make those groups, duplicate if needed. Note where there are sub categories. And then see what you can find out about these users. Do you have any data that tells you more about them? Find it. Start to learn more about them, can you identify them? See their most common tasks? See how often they come back? See where they drop off? Get everything you can. But if you all you can do is list them? That’s ok too. Because at least you’ve acknowledged they are there. At Rightmove we obviously have a lot users, typically people assume we are talking about buyers and renters. Of course, we are. But we’re talking about a lot more than that. I can say for sure that as someone who’s looking for their first ever house to buy, I am a completely different type of user to my 69 year old mum, who’s downsizing to a retirement flat. But which of us is more important? Is one of us more important? Why? And do we use the product differently? When you start to understand your users more, when you’re later discussing ideas, and solutions, you can tie them back to those users. Your success measures can be more specific. Something important I just add here - you are not a user. So I just mentioned the fact I’m a first time buyer? I still can’t refer to my experiences as a user (although I do a lot, and then have to backtrack!) I’m already tainted, I already know more than the average user, I’m too invested. And so are you.
- So now you have an idea of your users. Now you want to know, why do they use your product? Quick show of hands, who here has a user journey mapped out somewhere showing that users do on their product? Ok cool, and who here has an experience map? Looking beyond your product, but to the whole experience a user is having? Having the user journey mapped is important, it shows you what people are doing on your product, and can help highlight areas to work on. An experience map takes things one step back, and can be super helpful in offering insight away from your specific product. An experience map is a way to provide a visual representation of what your users do, think and feel over time. They start at the point they start to need a service (this could well be far before your product exists) Experience maps put the user at the centre of what you do, they can be used by everyone across the team as a point of reference, they can highlight the ‘low hanging fruit’, they’re great to find areas to innovate. They take time. I love to run, I do it a lot. I use a Suunto watch, and I use the soon to be discontinued Movescount app, it syncs to my watch, uploads my runs and I can check out the data. It also syncs to Strava. Strava could map out my journey as a user on their app. Or they could look at the whole experience, from me deciding to go for a run, to thinking about the route, to running, to finishing, to wanting to see what I’ve done, and telling others about it. *talk through the experience map on the screen* By looking at the experience map and understanding the pain points, and what you could solve. You are able to bring forward solutions to actual problems. I don’t know about you, but its not unheard of for me to be given something someone wants to be delivered, and then work with UX to see how to make it work. Using this tool, could allow you creating the starting point instead. Some reading: https://www.ngdata.com/creating-a-customer-experience-map/ https://medium.com/@wnialloconnor/how-to-build-an-experience-map-5e55b7ee4f32 https://www.gov.uk/service-manual/user-research/creating-an-experience-map https://gds.blog.gov.uk/2015/08/18/mapping-new-ideas-for-the-digital-justice-system-2/
- The final piece I’ll talk about today, is benchmarking. Benchmarking This doesn’t just mean who else builds the Product you build, but actually who else does something along the lines of what your product does? So at Rightmove, of course we need to know who our key competitors are, and what their product offers. But it’s as important (if not more important) for us to understand how people are using search, so google and amazon are key. Airbnb and booking.com, other property sites across the world. The key here is to understand what you’re looking at first - define the research upfront, and stick to it as you go through. If you find another point of interest, make a note of it somewhere else and move on. For example, are you comparing the whole experience (makes sense with RM and Zoopla), or an element of it (search searching and sorting functionality, the ability to draw a search on a map…) And what is the criteria you are analysing? Navigation? How many steps it takes to get through to a specific page? how the functionality works? The thing here is that you’re understanding expectations that are set away your product. We’d all like to think we set the standard, and some of us in the room may companies that kind of do. But the majority of us, need to look at the standards being set across the board and understand therefore, what our users are getting used to and starting to expect everywhere. So those are three key areas, often overlooked, and often assumed, that you should keep looking at and understanding. Who are your users, why and how they do use your product, and what’s happening elsewhere that could be affecting their expectations?
- I showed the traditional Product Venn diagram earlier, but swapped out the disciplines and focused on what should be covered by those circles not defining who does it. Remember those circles overlap, you need them all to get this right. I’ve been talking with colleagues a lot lately about this topic and I’d say this Venn diagram is a good starting point for really understanding the problems and opportunities as they’re balanced across the areas of users, what’s possible and business goals. But when you then want to try and solve those problems, or go after those opportunities, things change again. Now you’re onto the ideas stage. All those disciplines come back into play, but in a different layout XXXXXXX Now you want to be sure you’re thinking about UX within the development of ideas cycle. Working with the development teams to further understand what’s possible, and product to understand the boundaries, the balance, and what good looks like. Now you can start to work iteratively, building prototypes, testing them and optimising them. This shouldn’t be done separately, but should be part of your development process, the whole team should understand what’s being tested, and why, the hypothesis should be considered beforehand, and the success measures agreed. It comes back again to respect, respect for the disciplines, and what each other brings. If you just make an assumption, build it and see what happens, you’re dismissing what you can learn from users quickly and upfront. Prototyping and experimenting will allow you to make decisions based on what you know to be happening, rather than what you think might happen. But you need your users to get this right. Hopefully all this has given you some food for thought.
- The key takeaways I’m hoping you go away with are: Know everything you can about your users Remember, you are not a user (some might say, tainted) Look at their experience beyond your product, and then understand how your product fills a need Understand the expectations being set away from the Product you build Test and learn as part your development process, involving users throughout Have respect for all disciplines involved in Product Development, even if you don’t have a team dedicated to it Thank you.