DesignOps - How to get ideas out fast

Transcript

1. UX Australia 2019 -30th August, Breakout session (AUUXAU3008E) KRISTY SACHSE: Is this thing on? So I am Kristy and I will talk about design Ops. There's some articles online about design ops specific about designing but my talk is mostly focused on how designers and developers work together to get ideas out faster. So there's a lot of talk about dev ops at the moment, does anyone know what that is? Great. So the more I hear about dev ops there's one thing I don't hear about and that is how design and developers work so that's the focus of this talk today. Dev ops is people, developers, operations people, designers, copyrighters, everyone working together to get ideas out to people as fast as possible. It's important to get those ideas out fast because you can do heaps of user testing in a lab but we won't really know if someone wants to use your product unless it's in their hands. One person could have many different user personas. So the person that's using a movie ticketing system by themselves will be a totally different person to the persons that is using that movie ticketing system in the rain and with their children. So you want to start measuring some of those things in the real environment. So reducing the amount of research you do and getting it into the user's hands is kind of the dream. So how do we work together? This is my life cycle. Yours might be slightly different. Essentially, here we have organisational framing which is kind of understanding, you know, what do you want to achieve, where are your goals, you can have some really high level ideas and then we start getting into product strategy which is your double diamond, which is your convergent and di vergent thinking. And then we start building those features with, say, a development team and then you measure those features when they're in the hands of the users to say, or the people, to see if they're good ideas, is it worth doing more idea or should we pull the pin. So delivery process space, anyone can do delivery and anyone can do discovery. Fred is a designer and he can do delivery. This is Mo and he's a developer and he can do discovery. We work together to get ideas out fast and we use each other's experiences to speed things up. Having a developer doing discovery is great for several reasons. They provide a new set of eyes. So if I was wanting to know how can we do this as quickly as possible, they can let me know how that can be achieved or perhaps a new piece of technology that I wasn't even thinking about and also you wouldn't want to get a developer to give you some of those ideas after you've already done that user testing because that's just a waste of time, you tested something that perhaps may not have been achievable within a short period of time or maybe they've got a better idea. So you don't want to waste either. And also, if you're doing a whole bunch of research, like three months, and then you hand that over to a developer, there's probably going to be misunderstandings and also a they might be like "Why am I doing this?" And designer can be part of delivery itself because if something needs to change, it might need to change. Design is always an estimate. You're hoping this might be achieved but it may not be able to be achieved. You need to be there to help them change those ideas. You also need to have a definition done and I will show you what that looks like in a second and you also have to make sure the stories are user-friendly so that the products owner know what is happening, that it's not filled with tech speak. So, thinking about org frame ing and how designers is developers work together. After organisational framing you might have heaps of ideas. So if years of work, there's no
2. UX Australia 2019 -30th August, Breakout session (AUUXAU3008E) Page 2 of 3 prioritisation of what we should be doing, it's overwhelming for developers, and doesn't even need to be built. So how do you deal with all of this information? So that's why I start talking about designing a backlog. Do people work with backlogs? Anyone not work with a backlog? It's just a list of stories that you're going to start building and I find that if you dump everything inside the backlog it's quite overwhelming and developers can get anxiety from that thing. I would like to put a physical line, you can see the two physical lines that I've added. So one of them, anything below the line is out of scope, so it shouldn't be coming up in any of your velocity reports. Anything in the middle is where I like to discover things, so developers know what I'm working on before they come up. And then anything above the line is ready to be estimated and delivered by development team. So that's how I design my backlog. And I also like to match my user journeys or whatever user journey map you're doing with the backlogs. Backlogs are not linear. They have - they are prioritised. So you may not know how far away from the whole goal where we. You can add stories, you can remove stories but just at the start of the day you can all work around this wall and say OK, that's where we're at, that's what we need to achieve so maps your backlog to a user journey. So with product strategy, this shouldn't be done in isolation. Developers need to be part of this process. And a good way to do that is to put all of your ideas for that story on a wall and everyone can contribute to what they need to do technically, with design, with copy righting, whatever it needs to be, they all contribute on that wall. It's very physical and collaborative. And then lastly, delivery. So how do designers work within delivery. This is a very linear process. So we want to make it sort of iterative and nonlinear. And that's where dual track delivery comes in. So dual track delivery is exactly what it says. You have discovery at the top and delivery at the bottom. I've given two weeks in blocks here but you can use this at any length of time that you're comfortable with. For me, two weeks is enough time. So essentially I discover the first feature and then that feature goes down into delivery where it's built and after it's built, after that 2-week period we come up again and we're measuring to see if it's a good idea or not. You keep doing that until you've run out of time or money or whatever the reason. But there are times when you should be constantly delivering features. So as you're measuring feature one, you start discovering feature three. So you do have to do measure and discovery in the two-week period but I find that that's OK. And you continually do that. This is probably the most important thing, if you walk away with one thing today it's this. If a developer doesn't have a test or lab environment set up by the first, you need to put a hold on the project because you don't have anything for that product to go to and test when it comes up into measurement. So make sure that happens. And if they do, you can measure that too. Here's some quick tips. You've already run out of time so don't do a thing where you spend so much time on the first part of the project that when you get to the end of the project, you are basically doing a stick figure and a Smiley face. Measure it out. Layer on complexity as the time goes on. And don't build for a future that might never come. If you can't get that horse to work
3. UX Australia 2019 -30th August, Breakout session (AUUXAU3008E) Page 3 of 3 don't pivot and do a saddle because the horse may not come and you won't have a horse to ride. Don't get too far ahead of yourself. Two weeks is my preference. It's really about the team. And discovery can only exist while delivery time remains. So if you're seeing that the deliry -- delivery team has no more budget, don't keep discovering ideas and make sure you leave enough time at the end for you to do measuring of that last feature that's been pushed out. That's the definition of done, make sure you've got that. So does it look like what the wall said it would look like? Does it do what the wall said it would do? Accessibility testing, SEO, copywriting, image work, make sure all of that is on your definition of done. So that's how we can get together and design ops. The greatest story ever told. (Applause)