Agile UX and the Decentralization of the UX Department
•Download as KEY, PDF•
5 likes•851 views
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Recently uploaded
Recently uploaded (20)
Agile UX and the Decentralization of the UX Department
- 1. Agile UX and the Decentralization of the UX department Karri Ojanen © & ™or ® , Organic, Inc. Confidential. All rights reserved.
- 2. Waterfall How did you do that?
- 3. How did you do that? Agile Bob Jagendorf @ Flickr
- 4. 2 The waterfall development model has its origins in the manufacturing and construction industries.
- 5. Centralized How did you do that?
- 6. How didDistributed you do that? Mint Imperial @ Flickr
- 8. How did you do that?
- 9. 2 “Our time is so specialized that we have people who know more and more of less and less.”
- 10. 2 Centralization leads us into specialization.
- 11. 2 “Nothing is as dangerous in architecture as dealing with separated problems.”
- 12. 2 Specialization drives us into separation.
- 13. How did you do that? alexanderdrachmann @ Flickr
- 14. 2
- 15. 2 Stop advocating a separate UXD group.
- 16. 2 Stop advocating a separate UXD group. Stop advocating yourself as a specialist.
- 17. 2 Stop advocating a separate UXD group. Stop advocating yourself as a specialist. Start talking, listening, and questioning (yourself).
- 18. 2 Stop advocating a separate UXD group. Stop advocating yourself as a specialist. Start talking, listening, and questioning (yourself). Don’t ever miss the opportunity to co-operate.
- 19. 2 Stop advocating a separate UXD group. Stop advocating yourself as a specialist. Start talking, listening, and questioning (yourself). Don’t ever miss the opportunity to co-operate. Take responsibility for more than just your own field.
- 20. 2 Tell me, and I’ll forget. Show me, and I’ll remember. Involve me, and I’ll understand. Karri Ojanen Sr. Experience Architect - Concept Designer - Strategist conceptology.org finnformation.net twitter.com/karrio
Editor's Notes
- We all know, and are familiar with the waterfall process model, in which progress is seen as flowing steadily downwards through the phases of Requirement gathering, Conception, Design, Development, Testing and Maintenance. One phase of a project at a time gets done and approved, and then we move on to the next phase.
- Agile process isn’t just one process model, but a group of models, and therefore can’t be as neatly and easily defined as the waterfall model. In general, agile methods promote a disciplined project management process that encourages frequent inspection and adaptation. The work takes place in cycles - cycles that require teamwork, self-organization and accountability. In the agile model, instead of executing and approving one block at a time, the team tries to establish a more holistic view of every aspect of the project, and use constant iteration to better meet both customer needs and company goals.
- The waterfall development model was developed in the industrial era, the time of mass production. Back then, software development was completely new as an industry, and since no formal development methodologies existed for this new line of work, the hardware-oriented model of “waterfalling” through the process was simply adapted for software development as well. It’s based on the hard reality of industrial manufacturing: since changes to earlier completed phases were either extremely expensive or downright impossible, the phases inside the process must be well-structured and closed. If you’re building a big cruise ship, for example, it’s both expensive and difficult to go change the work that you have already done.
- Now let’s look at another thing: the way we are used to organizing ourselves into teams around competencies. Most of us are used to centralized structures. When a team is centralized, it’s a team that “owns” its discipline and supplies it to development teams on projects across the organization. Teams like “user experience”, “creative”, “development” or “strategy”, for example. A centralized usability group would conduct all user testing and other user research, and come back with expert recommendations to other teams or work groups. Similarly, a centralized design team would supply all interaction and visual design, perhaps. This centralized structure provides a home for specialized staff members, and it’s usually thought that it makes it easier to manage and promote the staff. It may feel like the most natural choice to create centralized teams.
- But distributed team structures avoid that kind of centralization, and instead assign specialized staff members to work directly on individual project teams. In this structure, each project team has its own usability specialist, interaction designer, visual designer, developer, writer, and so forth. The biggest benefit of the distributed model is that then everybody has to play together, with less of an option to run things from their own, specialized chambers. And user experience design, in particular, is something that should be considered a part of the project team, its every member, not an outside department. Every member of the team, whether specialized in usability or not, should work to ensure good usability, and good usability comes from the sum of all components: design, technology, and content.
- This guy is Alvar Aalto. He’s a famous Finnish architect, perhaps the most famous of them all, though he’s not the Finnish architect who designed the Toronto City Hall. That’s Viljo Revell. Alvar Aalto was a designer, architect, and pacifist, who’s often called The Father of Modernism because of the style of his work.
- Alvar Aalto is famous not only for his architecture, but his furniture, textiles and glassware. Most notably the Aalto vase which is in this picture.
- Alvar Aalto talked a lot about how people organize their work and their disciplines by specialities, by expert opinion and committees. He saw that as a problem. Of specialists, he said that they’re people who know more and more of less and less. He himself, as testified by the diversity of his work, liked to learn and know about several things.
- Centralization, as in centralized work teams, leads us into specialization. Despite of Alvar Aalto’s words, there’s nothing so horribly bad in specialization in and of itself - we all need to specialize in something, we can’t all be know-it-alls.
- But Alvar Aalto also said that in architecture, nothing is as dangerous a dealing with separated problems.
- Specialization can drive us into separation. That’s the real danger of it. Once we specialize, we begin to lose touch to other disciplines, and deal with problems that are separated from other disciplines realities. It becomes more and more difficult for others to understand the work that we do, when they’re not involved in it, and we’re not involved in theirs.
- So how can we, as user experience designers, or interaction or visual designers, fix this?
- Five things. First, stop advocating a separate UXD group. Instead, try to become part of all the other groups. Get others concerned and excited about what you do. Also, individually, stop advocating yourself as a specialist. User experience design, information architecture or interaction design aren’t always exact sciences, and neither they should be. Collect feedback from others and accept the fact that sometimes it’s the developer or the writer who comes up with the solution to your problem. Start talking, listening, and questioning more, get involved, and let others do the same. And take responsibility for more than just your own field. Be the creative director, the writer or even the developer sometimes. Not literally maybe, but don’t let go of your responsibilities where you feel like your narrow expertise ends.
- Five things. First, stop advocating a separate UXD group. Instead, try to become part of all the other groups. Get others concerned and excited about what you do. Also, individually, stop advocating yourself as a specialist. User experience design, information architecture or interaction design aren’t always exact sciences, and neither they should be. Collect feedback from others and accept the fact that sometimes it’s the developer or the writer who comes up with the solution to your problem. Start talking, listening, and questioning more, get involved, and let others do the same. And take responsibility for more than just your own field. Be the creative director, the writer or even the developer sometimes. Not literally maybe, but don’t let go of your responsibilities where you feel like your narrow expertise ends.
- Five things. First, stop advocating a separate UXD group. Instead, try to become part of all the other groups. Get others concerned and excited about what you do. Also, individually, stop advocating yourself as a specialist. User experience design, information architecture or interaction design aren’t always exact sciences, and neither they should be. Collect feedback from others and accept the fact that sometimes it’s the developer or the writer who comes up with the solution to your problem. Start talking, listening, and questioning more, get involved, and let others do the same. And take responsibility for more than just your own field. Be the creative director, the writer or even the developer sometimes. Not literally maybe, but don’t let go of your responsibilities where you feel like your narrow expertise ends.
- Five things. First, stop advocating a separate UXD group. Instead, try to become part of all the other groups. Get others concerned and excited about what you do. Also, individually, stop advocating yourself as a specialist. User experience design, information architecture or interaction design aren’t always exact sciences, and neither they should be. Collect feedback from others and accept the fact that sometimes it’s the developer or the writer who comes up with the solution to your problem. Start talking, listening, and questioning more, get involved, and let others do the same. And take responsibility for more than just your own field. Be the creative director, the writer or even the developer sometimes. Not literally maybe, but don’t let go of your responsibilities where you feel like your narrow expertise ends.
- Five things. First, stop advocating a separate UXD group. Instead, try to become part of all the other groups. Get others concerned and excited about what you do. Also, individually, stop advocating yourself as a specialist. User experience design, information architecture or interaction design aren’t always exact sciences, and neither they should be. Collect feedback from others and accept the fact that sometimes it’s the developer or the writer who comes up with the solution to your problem. Start talking, listening, and questioning more, get involved, and let others do the same. And take responsibility for more than just your own field. Be the creative director, the writer or even the developer sometimes. Not literally maybe, but don’t let go of your responsibilities where you feel like your narrow expertise ends.