UX: Don’t Hate, Participate
In my January article, The Adventures of Usability Girl: Building UX from the ground up, I shared my experience of building the UX team at AT&T Interactive (ATTi) and discussed some tactics for building legitimacy of UX in a company. One of the most effective ways to do that is to bridge relationships cross-functionally across different teams, and find ways to get the other teams interested in UX.
Gaining constructive participation of other teams is imperative to legitimatize your UX organization and to help ensure that UX is fully integrated into and utilized in future projects. Other teams will trust and depend on your team more when they understand your process and feel like they are participating. Also, the more collaboration and teamwork you incorporate cross-functionally, the more confident you can be that you are utilizing all available resources to design a product that everyone is proud of (and bought into). Bringing other teams into the UX process allows you to ensure that your designs are built and reviewed with different lenses and perspectives.
So how do we do this? Working with a lot of different teams, I’ve found that they each want to be integrated into the UX process in different ways. However, there are definitely some common threads. Here’s my approach to looping in the executives, the product team, and the developers.
The big dogs are the ones who can be the trickiest to integrate into your design and research process. Not only do they have consistent bandwidth constraints, but you also have to walk the fine line of keeping them involved while not pulling them into the weeds where they can get inundated with the details.
Executives want to know what you are doing to provide results and returns. Unlike other teams, they are not as concerned with the details of how things should be designed. So to gain constructive participation of this group in aspects of UX design and research, it helps to speak the language of data.
The UX team is usually considered the creative, artsy-fartsy, touchy-feely team of the company, whereas other teams are perceived to be more data-driven. Since UX is considered a largely creative process, we need to find data-driven ways to pull in the participation and understanding of executives. Usability testing is invaluable for this. At ATTi, we invite the entire executive team to weekly usability sessions. After the sessions are run, I share our high-level findings in a weekly readout, so that even if the executives were not able to observe the sessions, they can still be privy to our results. And to take it a step further, twice a month we review our most recent design comps with the CEO and other members of the executive team, and walk through how our usability findings and other user research has informed our design decisions. Throughout this process, I also urge the executives to take the time to use our products as often as possible. This allows them to come up with their own feedback for our designs.
The trick with this group is to use their time efficiently. Get to the point. Show them data. Don’t inundate with details, but show progress. And definitely find a way to keep them informed and interested.
The Product Team
Along with the developers, these guys are your partners in crime.
Whereas the executives participate in the UX design and research process from a more removed, high-level perspective, the product team keeps you company in the trenches.
I have found that the best way to gain the constructive participation of the product team in the UX design and research practice is by constant communication. We hold kick-off meetings with the product team when a new project comes down the pipe so that we can hear what each project is trying to accomplish and we can start to collectively brainstorm UI ideas. That way, once our interaction designers start putting together wireframes, they have a better idea of what the product team is looking for. In addition to the kickoff meeting, the product team participates in brainstorms with UX and reviews of wireframes and design comps.
Of course, it is best to find the balance between too many meetings and not enough. What I’ve found is that the stronger the relationship between the product and UX teams, the less of a need there is for formal meetings. Instead, both teams feel comfortable approaching each other more informally for collaboration, questions, and sharing. The better your relationship with your product manager, the easier it is to gain constructive participation from them in the UX practice.
In addition, I invite and urge the product team to attend usability sessions. They are invited to participate in the direction of the research script (what we are looking to test), and they also take part in the debrief session going over findings and recommendations. From these debrief sessions, they are able to see where they can fine-tune their product from the functional requirements side, and they can also see what issues UX needs to address from our side.
Similar to executives, seeing UX research that supports decisions helps pull the product team into the UX practice. The product team at ATTi likes to see how the UX team utilizes competitive research, best practices, and UX research done by our team and other UX teams towards UI decisions. Being privy to how the UX team makes their decisions gives product a deeper understanding of how we are solving problems, and also lets them see and appreciate our process.
So what’s the trick with the product team? Communicate regularly. Establish collaborative relationships. Invite them to take part in brainstorming. Give them a peek into what has motivated your design decisions (usability, outside research, competitive research, etc.). Treat them as a partner in UX, and not as an outside threat.
The approach to gaining constructive participation of the development team is similar to the approach for the product team. And like the relationship with the product team, it is most successful with a lot of communication and collaboration.
Usability testing is valuable to the developers, as well. It is one of the only times that the developers are able to get insight into end users, and it allows them to see the product through a completely different lens than they are used to. Not only that, but they also get a chance to see real users interact with a product that they’ve worked hard to develop. They can see the product from a different perspective, and also experience the reward of seeing users use and enjoy what they’ve built. Therefore, we urge the development team to attend usability sessions, and also participate in the debrief discussions after testing and analysis is complete. This way, they can see firsthand what issues we’ve come across, and we can work collaboratively to find ways to solve them.
And just like with the product team, we invite developers to brainstorms and reviews of UX deliverables such as wireframes and design comps. Engaging developers in this way really is invaluable, as it gives yet another perspective on the product design in conjunction with the perspectives of executives and the product team. Oftentimes, UX teams are trying so hard to move quickly that they overlook how valuable it is to involve developers early in product discussions. They are a great source of ideas, and involving them in early discussions allows you to explore new ideas as well as get a reading on the viability of your UX solutions.
So how do you engage the development team in UX design and research practices? Communication. Show and tell. Collaboration and brainstorming. Involve them early and utilize their potential as a sounding board for ideas and solutions.
The Common Threads
As I mentioned, different groups want to be involved in the UX design and research practice in different ways. It is important to spend the time to carve out the best way for each group to be involved, which depends on developing a good relationship with each group and also finding the best way to keep them interested and involved in UX. I discussed the executive team, the product team, and the development team, but a lot of these approaches can also be applied to other teams, such as marketing.
By honing in on the language that each team speaks when they view UX, you are able to provide them with the services that they are looking for. UX creates a lot of different deliverables and outputs. It is important to get an understanding of which output is most important to each team. For some teams, the research output is most important. For others, it is the UI deliverables of wireframes and comps. By understanding what is important to them, you are able to show them that part of the process that interests them.
Usability testing is invaluable for cross-collaboration. Urge participation from any and all groups. Once people watch their first session, they are hooked. There is something fascinating about usability testing. And to fully appreciate the value that usability testing brings to the organization, it is imperative to watch it firsthand.
And finally, I cannot say it enough: relationship building is key. The better the relationship you have with your product resource, development resource, and your executives, the easier it is to draw them in and get them comfortable in constructive participation with your team and what you offer. And getting them to feel like they’ve taken part in what you’ve designed, and to know how you made your decisions, makes generating buy-in for your end solution (and your team!) a lot easier.