UX has in many cases been an afterthought on fast moving projects. There are distinct ways to approach the integration of the user experience process into the product development process and we will explore a couple of these here. To get more insight, I interviewed two UX designers that I have worked with to get feedback on how two different styles of integration affect them, the teams and the product as well. Details of what seems to work and what does not are presented below.
The least effective approach towards UX that I have observed is the retroactive approach, where the rest of the development process is agile, but interaction with the user experience group is in a waterfall manner. Team produces a product as the business analyst and/or product owner specifies it and then it is sent over to the User Experience group for evaluation. UX makes recommendations and based on the time available in the project or whether the dev team has moved on to other features, the recommendations are implemented or put on the backlog for "future".
The second approach is also that of UX as a service but more in step with dev teams. The UX group advises the analysts and works with them during the initial design phase of the project. There is a primary resource assigned to the team that can be reached out to at any point of the development process. The primary resource attends sprint reviews and gives feedback to the product analysts, if they see any need for a design change. This is a much more "agile" approach as it makes it possible for the team to get feedback, at least at the end of every iteration.
The third approach is the one where dedicated user experience resources are a part of the team. They are embedded and function just like every other member of the team, being involved in stories from kickoff to reviews. They are able to provide constant feedback and get an idea of the technical constraints the team is working under. At the same time the dedicated resources are able to provide a slight paradigm shift in the mindset of the team. The entire team can benefit by becoming slightly more user focused as that is the perspective the user experience folks use to look at the product.
I talked to a couple of folks that I have worked with to get their feedback on the last two approaches outlined here. Lauren Martin and Bruno Torquato agreed to participate and help me out in drawing out the distinction in outcomes from the two approaches. Here are the advantages of both approaches as outlined by them.
- Advantages of UX as a service
- Creative Inspiration - Lauren points out that being in the same space as other UX designers helps promote an environment where since everyone is involved in a similar creative activity, creative inspiration flows a lot more freely. This is harder to attain in an agile team setting where you are separated from the broader UX team/department.
- Mentoring and Sharing - Working as one group providing a UX service, allows for opportunities to mentor less experienced team members and also the ability to share ideas and discoveries. "Cross pollination of ideas" according to Bruno is more natural and less forced as it has to be with UX being embedded on agile teams.
- Planning and Execution - Lauren feels that it is easier to create plans and help with the long term execution of these plans. Also there are fewer ad-hoc requests from the team that could potentially derail the longer term plans,
- Objective Perspective - "Outside perspective can give you space to provide insight", says Bruno. He believes that the deliverables that he provides are not "colored by the immediate needs" of the team when working in a UX as a service mode. It allows the designers space to provide insight that might be lost with the embedded perspective.
- Advantages of Embedded UX
- Greater Visibility and Understanding - There is increased visibility into the processes used by the designers. Lauren believes this helps the "team have a broader understanding" of what designers do and how they get to the resulting deliverables.
- Team Ownership - Embedding user experience designers in the teams helps the team own the user experience as a collective. This enables Bruno to disseminate his "perspective and have the rest of the team take ownership" of the design as well.
- Realistic Expectations - With the increased visibility and understanding come more realistic expectations from the team. It becomes easier for the team to understand whet the designer is shooting for. Rather than finished full scale designs being passed to the team, designers can work on a small scale where expectations are clearer.
- Immediate Iterations - Desk checks and story reviews help make sure that design can be iterated upon quickly and at times almost as soon as it is implemented. Sometimes, this is before it is implemented, if the team has technical limitations or any other obstacles that come up, the designer can help remove those or modify the design as needed.
Both Lauren and Bruno made excellent points that can not be summarized simply as advantages of these systems. They both at this point work as embedded designers an agile teams. Lauren remarked how when being embedded, at times "creative flow is almost impossible to attain". On her team, the two designers have had to split responsibilities between "just in time and work ahead" responsibilities to make sure they can maintain creative flow and respond to team requests.
Bruno makes a point about the being within the team lays "more importance on developing relationships within the team" and the fact that the dynamic within the team can help with having more momentum with the project. Another advantage of team specificity mentioned by Bruno is being able to adopt process to product , i.e. use the ideal process based on team and product type.
Last bit though, my favourite quote from the interviews -
"It still depends on the team, and the system does not matter as much"- Lauren.
Rings very true, raising the team's consciousness is more important than the system the UX folks work in.
No comments:
Post a Comment