Helping multi-discipline teams become UX advocates
We’re all in this together.
As the tech world continues to vigorously soar forward companies are constantly needing to adapt and respond to their surroundings. With older software companies this means huge culture shifts in process and implementation. Having a strong, flexible UX process allows entities to react not only to their customers, but to their competitors as well.
Integrating a fluid UX process into more mature software companies presents some interesting challenges. How do you deal with push-back? How do you help teams not feel what they had done previously was not a waste of time? How do you help others see the value and power of an integrated UX process?
FROM OBLIGATION TO DESIRE
A product I work on supports higher-education institutions from faculty and staff to students and parents. For over 25 years it has evolved into a powerhouse in managing these multiple facets. Over the past few years, elements of a UX process began trickling in. Reception was understandably both hot and cold.
When I entered the scene, we supported teams that fell across this spectrum; some teams where happy to have us, some teams thought we were just button creators. There was a need to help evangelize the importance of UX. Over the next year, we were able to convert many. Here’s how we did it.
STRUCTURE AND CONSISTENCY
Stability of any process is paramount in creating a successful product. To promote this stability we had to make sure that the teams we supported were fully aware of our involvement. Initially, we started attending every team meeting we could. They needed to know we were there for them; that we cared. This ended up averaging 3–5 hours of meetings a day. It was NUTS! Ultimately we were stretched too thin. Something had to change so we could actually implement our action items.
They needed to know we were there for them; that we cared.
Trying to be everywhere was not working. With what little time we had remaining, we weren’t able to fully implement a UX strategy when needed. After some time, teams were able to see a glimpse of our potential. With this, we were able to make a shift. Instead of us going to them, we proposed they all come to us. Instead of us being on multiple Jira boards, they came to ours. Instead of us being chained to their sprints, we were on our own time table.
It was a success! After a brief trial time, we reached out to see how the teams were responding. They (well, most) loved it. We opened up consistent office hours three times a week so they knew when they could get face-to-face time. Open communication was crucial. Instead of 15+ hours of meetings a week, it was down to five(ish). We were able to be more proactive rather than purely responsive. We could hold more user-testing sessions, have more time for journey mapping, and develop clearer personas. Overall we were able to do our job as intended. We were able to iterate quicker since we weren’t tied to a three-week sprint.
This really smoothed out our work flow. Not only were we able to be more productive, but we could dive deeper into projects when needed. Now, in now way was this perfect with all the teams. There is still a way to go with some of them. We understand that this is a fluid process and are striving to adapt as needed.
TRANSPARENCY THROUGH COLLABORATION
In order for our teams to trust the UX process, they needed to experience it first hand. It was imperative that we break down existing reinforced silos and nurture an environment of collaboration. This required complete transparency. We started involving business analysts to our user tests. We invited developers to our brainstorming sessions. We started to solve problems on the spot as they were presented to us to get the team’s input. Not only were we able to expose our process, we were also able to get a flood of ideas from those who knew the product best. Our solutions were more viable with buy-in from team members because they were involved.
Not only were we able to expose our process, we were also able to get a flood of ideas from those who knew the product best.
BUILDING RELATIONSHIPS OF TRUST
If we wanted to succeed in our roles, we needed our teams to believe we could deliver on our promises. We needed to gain their trust. Over time we were able to help them see the value of what we offered. We admitted when we needed to further understanding, and were completely open to their feedback and criticism. This opened many two-way conversations that led to better results. We never just told the teams what to do. We presented what we worked on and gave our reasons. We gave them substance, not just fluff. We were happy to go back and iterate as business rules became clearer or goals changed via user testing.
We never just told the teams what to do. We presented what we worked on and gave our reasons. We gave them substance, not just fluff.
Overall strides have been made. Are things perfect? Of course not. But a strong foundation has been set to build upon. A foundation based on structure, collaboration, and trust. As we improve this process, our outcomes will as well.
What has worked for you as you implement a UX process? Have any of these ideas succeeded? Any failed?
This was adapted from a case study I wrote for my website at iamjacobrussell.com
