UX Design is Team Work (Agile & UX)
•
7 j'aime•2,410 vues
Related Blog post: http://www.mangrove.com/blog/1170/ux-design-is-team-work ------------------- A lot of people in the UX field struggle with the transition from waterfall to an Agile/team process. Because we were doing very well, right? We had a complete workflow set-up. We had this great list of deliverables. This old play-an-department thing was absolutely brilliant for the UX discipline. Everybody seemed to be happy with us. Well. We thought. Because I actually think that our old UX design workflow was one of the MAIN reasons we switched from waterfall to an agile process. A lot of our "deliverables", whether they were wireframes, flows or specs, implied that we could grasp the whole product in advance. The results gave security, to our clients, sales persons, developers and others. In this presentation I dive deeper in the background and our lessons learned so far.
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
UX Design is Team Work (Agile & UX)
- 1. Ruben Bos UX is team work UX cocktail hour Rotterdam Mangrove, 18th of december 2012
- 2. about
- 3. about us
- 4. about agile
- 6. about ux
- 7. security
- 8. false
- 9. why are we working agile?
- 10. why are we working in teams?
- 11. "The biggest irony of the shift to Agile is that it's exactly what the UX world has been seeking for years. Yet now that it's here, we're wholly unprepared for it." Jared Spool
- 12. what we’ve learned (and keeps changing)
- 18. more skills, less people
- 19. who owns ux?
- 20. 1 make ux part of the team
- 23. 2 become an ux facilitator
- 24. "Yet because we couldn't have fast development iterations, we filled up our toolbox with techniques to deliver fullythought-out designs to the implementors. This left little wiggle room. And we got good at it." Jared Spool (again)
- 28. so we better get good at it
- 30. 4 research and design up front?
- 36. 4 research and design up front (but just enough)
- 37. to round things up
- 38. interested? • UIE.com • JohnnyHolland.org • AgileProductDesign.com ! • Sketchboarding by Adaptive Path templates & article: http://bit.ly/uxsketch
- 39. thanks for listening! Ruben Bos @rubenbos ruben@mangrove.nl @mangrove
Notes de l'éditeur
- I currently work as a Creative Director, started 7.5 years ago at Mangrove, studying Media Technology, mainly as a front-end developer. Through the years I extended my work to other fields, like User-Experience design but also concept, strategy and copy writing. So first of all, you guys are probably way more into Experience Design. But, if I wanted it or not, at one point a few years ago, a large part of my daily job existed of UX related tasks, like writing functional specs, wire framing, research and prototyping.
- And as we were growing as a company, from let's say 10 to 30, for a short time we thought: now we're going to have a design department, a front-end department, a development department. And in this waterfall, together with a few other colleagues, we could consider ourselves "the UX department".
- Then, about 3-4 years ago, we did a major transition at our company. We went Agile. Well, or SCRUM, or just: work focussed together in teams to make awesome stuff. Because I'm not really into this terminology thing. I assume you already know something about SCRUM,
- In short: - we no longer detail every specification in advance. - instead: we define desirable ‘user stories’ and prioritize these. - we work with a fixed team with different fields of expertise We work in timeslots of 2 weeks, we call sprints. Every day we have a daily stand-up to track progress and problems. After each sprint, we deliver a working product. This approach makes it possible to adapt the details to new insights and priorities
- A lot of people in the UX field, including me, struggled, or are still struggling with this transition to an Agile/team structure. Because we were doing very well, right? We had a complete workflow set-up, we have this great list of deliverables. This old play-a-department thingie was absolutely brilliant for the UX discipline. Everybody seemed to be happy with us. Well. We thought.
- Our "deliverables", whether they were wireframes, visual designs, flows or specs, imply that we can grasp the whole product in advance. The results give security, to our clients, sales persons, developers.
- But for us, in the digital industry, I think this was a false SENSE of security. Projects went out of scope. If predefined design decisions didn't make sense - to developers or others - they were hard to alter. Functional specs turned into contracts instead of collaborations.
- So now we, Mangrove, are 'agile', or better said:
- team working. And we're working with User Stories instead of these big spec documents. And our experience after these 4 years is not that it solves all problems, but there are clear benefits, to work agile: - iterate fast - no department culture, say he’s a bastard if he is sitting besides you - client can join and become part of the decision making - we can work with fixed budgets and short time planning But also for UX specific, I think there are clear reasons why we should adopt these new principles.
- I actually also think agile is what we’ve been seeking for. And we were also unprepared, but much more experienced now. So what I would like to do is to take you through some projects and explain how we manage to keep a strong focus on user-experience after our shift to agile. 'User Experience' can become quite an abstract term. Focussing on so many domains, from research to interaction design to visual design. But also offline or online.
- So I would like to show you examples how we have managed to embed UX tasks in our process A lot of them are 'interaction design' tasks, but also visual design etc. So I'll just call it UX design And it’s about HOW WE HANDLE IT: A digital agency, that works agile. So don’t feel offended if the story doesn’t suit you And our learnings UNTIL NOW. I say until now. Because Agile itself, is also iterative. We constantly try to improve the way we work. Even in these examples, there is difference in how we approached it. I will probably say different things if I give this talk another year.
- We work in teams that are about 4 - 6 man big. One or two developers, a front-end developer, a designer and a team leader. Major design decisions are all made during the sprints by the team.
- So let's start with our own website. Mangrove.com. Which is an extremely responsive website. Please buzzword bingo along with me In Responsive design we have hundreds of different states. A lot of these states depend on what's possible, design-wise and development-wise. It's a close collaboration between design and front-end. We wouldn't have come up with the same results and solutions, if we would have designed the whole experience before we started developing. The code is a crucial part of the experience. FOr example the timeline
- Inspire Conference, a web design conference that took place last week. And in this project we even worked together during the development with both design, code and illustrations to make the website look and work great on all screen sizes and devices. We had some rough sketches, but the whole thing only got clear when we were developing.
- - last year we got asked by Seachange to create a multi-screen solution - Seachange provides the back-end of nearly all major TV operators worldwide - they also wanted to offer tablet, smartphone and desktop apps to the operators - where users can watch Live TV and buy movies - the challenge: the product was already pre-designed. Wireframes, visual design everything - very waterfall. But they already failed with building it We sticked to our principles, and did our own way: - teams started with nothing else but user stories - teams redesigned and iterated in the sprints - a lot of functionality and features were depending on the back-end of Seachange Eventually this turned out well. Big parts of the earlier designs, turned out to not make sense. Or were no priority at all. - user accounts, billing, programming guides, video on demand - the scope was so big, that I really believe that our way was the only way to be able to actually deliver a project VOO launched VOOmotion earlier this year
- Video: Connecting Andrei Herasimchuk - Director of design, Twitter
- Our projects are getting more complex, have to work on different screen sizes, devices and different technologies. These projects ask for more skills. While productive teams ask for less people. Less specialized people.
- The role of UX designers is changing. We no longer OWN the user experience of the website we're designing. The team constantly has to make decisions that influence user experience and flow. I believe that these skills are already there. That the multidisciplinary teams can work together to solve Ux design problems.
- So, when we started making the transition to agile teams 4 years ago, we also added UX to the set of skills that everyone at the company should master. Of course this depends, which role you will fulfill in the company. Naturally we want some, like an art director, to have a high level of UX skills. But also our developers and front-end developers have a great sense for Experience design. We consider ourselves a Experience Design Company.
- Hire the right people That's why we hired Ivana, not only because she's an awesome front-end developer, but she also knows her UX design.
- Or Jeroen, who is a back-end developer, who won't hesitate to draw out a better version of your booking flow. User Experience isn't just the field of 'UX designers'. Everyone understands, or should understand, what it takes to create awesome experiences. And the different perspectives makes this better. Our designers and developers are not just 'visual designing' or 'developing'. They're solving problems, with the best possible experience. So also for developers, code is just one of the ways to reach that goal.
- But in Agile, we don’t care for deliverables. We want “working software over detailed documentation" and "responding to change over following a plan." In an Agile project, you can't just drop the deliverables on the table and move on." UX is not about dropping a bomb (deliverables) and running away
- I believe the role of more skilled UX practitioners in an agile environment is to make UX a skill of everyone. Stuff like card-sorting techniques are TOOLS. Tools that should make things clear for everyone, not just the 'UX designer'. If you consider yourself an UX expert, your role should be to help OTHERS learn these techniques so that they can use them. Do workshops, train team members, sketch together. Make sure, all team members are capable of making decisions that influence UX. Appsterdam, Kroket app
- Once you're working - on responsive designs, apps or other interfaces - in an agile team, you know one thing for sure.
- Everything will change. Constantly.
- So instead of getting frustrated, we can better embrace techniques that facilitate experimenting.
- One of my favorite techniques is Sketchboarding. A sketching technique by Adaptive Path, that let's you find good solutions together in a team, in a really short time. With Sketchboarding, it's all on paper. Which makes it really easy to discuss solutions and change them if needed. Involve everyone in sketching. And everyone become owner of the solution.
- So we moved a lot of UX related work from 'big design up front' to development sprints. Is there still a role at our company for UX research? Usability? Of course there is! As you can imagine, these teams work in sprints of 2 weeks. In these sprints the focus is on completing user stories. There is less time for extensive research. So what do we prepare?
- For example, for a recent project we tested with the target group before we started sprinting. We first wanted to what their feedback was, and used mock-ups to make do so. The whole team, including the client knows that the eventual product will be radically different than our tested designs. But it gave us more insight in advance of building, and we could base the user stories on the testing results. So with research, if it's needed in advance, we'll do it. But also if it's needed after sprints. For example, for the client we tested in London we are currently working on a working prototype, in sprints, that won't be launched, but will be tested again, before we turn it into a launchable product.
- Most of the time, we prepare visual design direction, because that needs time. Both for us, as the client. But even in this phase we try to make them suitable for agile. Style Tiles Moodboards So we won't make complete designs. And if we do design in advance, it must have a clear reason.
- Or Marketingfacts, where prepared a rough structure on a wall, that we could extend during the sprint So we won't make complete designs. And if we do design in advance, it must have a clear reason.
- Or Marketingfacts, where prepared a rough structure on a wall, that we could extend during the sprint So we won't make complete designs. And if we do design in advance, it must have a clear reason.
- 1) make ux part of the team 2) become a UX facilitator 3) prototype low-fidelity 4) research and design up front (but just enough) So the title of this talk was UX is Team Work. Do I mean with that, that everything should be a compromise? No way. Contrary actually. Everyone should focus on what they’re best at. But whether you like it or not, the eventual User Experience, will be a result of the complete team, from researcher, to copy, to development. In that perspective: is waterfall the real compromise.