Role of UX Design in Building Products: How I Stopped Designing and Started to Love my Developers!
How I Stopped Designing and my Developers started to love me!
This is my talk at UXIndia14, where I shared my experiences working as UX Designer with companies building products. If I had to summarise my role working on building products it has be this:
“I facilitate and guide teams to build usable products and services”
Traditionally, UX teams have been the glue between businesses and their customers, who held the barriers high to keep bad design choices away from the customers. This notion of UX team being the ones who are in touch with customers is changing, more departments within the company are now mandated to talk to customers directly for inspiration and insights. The role of the UX Designer is changing and Peter Merholz draws the parallel to a Film Director. He says
“UX Designer support the orchestration of organizational resources to deliver great experiences.”
This is not a new notion, Don Norman summarized his role working with Apple at CHI’95
“We describe the role of the “User Experience Architect’s Office”, which works across the divisions, helping to harmonize the human interface and industrial design process across the divisions of Apple and ATG.”
This just boils down to this, the responsibility to deliver a delightful experience through a product cannot be with a person or a team.
Another trend that seems to emerge lately is that persuading teams to make better design choices is the second in list of top UX activities as shown in the Annual UX Careers Survey by NN Group.
This raises two important questions for UX Designer working on products:
- What new skills do UXers have to learn?
- What new processes allow us to do our jobs more efficiently?
What new skills do UXers have to learn?
UXers are great at talking to customers/users/clients to understand their context, environment and their pain points through various research methods we employ. Why not use the same skills within our organizations as well? We know that the way we see others is not the same as how they see themselves. Why do we spend large amounts of time cribbing about our development processes and the developers on team. Maybe we could spend some of the tools we know to emphasize with users in our daily work contexts. Few things that I do to build inward empathy:
- Know the teams’ mission/objectives
- Understand their goals/task flows/pain points
- Practice active listening with colleagues in cross functional teams
- Know when to push / pull back
What new processes allow us to do our jobs more efficiently?
Let me break that down to the two phases of projects, Research and Design, and talk about a few simple things that worked in involving the entire team in the UX process. This involvement of the team, demanded that the entire team spend more time on creating and observing design artifacts, but it resulting in saving a lot of time eventually as it eliminated the need for meetings and discussions trying to convince the development team and management on what choices to make in the design of the product.
During Research Phases
Recordings and reports of the user research are a big time and resource hog that are never seen again. Usually for any research activity, I have started to get buy-in for both budget and resource time. Resource time, that of the team members on the project, so that they can be part of the process and see the users’ reaction or environment first hand, that helps the team members to empathize with the user much better.
In a case where UX team is small and supporting a large number of product managers, we have taken time to train the product managers in conducting research. This helped us reduce the time to bring ideas to execution drastically and ensure we were building the right services and products.
At MathWorks, as a policy the UXers do not conduct usability testing unless there is a team member present during the session. This ensures that the team members empathize with the user’s pain points and also no more long hours of report generation.
During Design Phases
I have talked to many UX Designers working in product companies, where their biggest pain point was the number of prototypes and wire-frames that UXer would build is way higher than the actual designs are that are built by their teams. When I probe more to find out why this is the case, it mostly boils down to the fact that the UXer was working in a silo building wire-frames and when they finally show it to their teams, they spend way too much time convincing and negotiating their designs.
We UXers are very possessive about the designs and wire-frames, we like to be responsible for them and also take ownership. What if we can let go of ownership? What if the team comes up with the design with the help of the UXer’s guidance The team being part of building the wire-frames exposes them to the constraints and options that UX designers care about and they are also able to bring up the technical and business constraints that the UXer would not normally know of.
The tools that we use play a major part in how easily the team is embracing the ownership of building the design along with the UXer. Typically paper and whiteboard worked well for me, they have the least path of resistance. Everyone knows how to use a paper and marker pen. There are no new tools to learn. Using these low fidelity tools makes people more collaborative during design workshops. Once the team agrees on the prototypes built on paper, we have directly jumped into building the front end of the feature/application in browser and iterating it until we finally got the result.
In some situations, I have had a front end developer involved during the early stages of the requirements of a project, where quick and dirty prototypes were built to ensure everyone was seeing eye-to-eye in how the product/feature will behave.
UXers empathize with your development team, figure out their pain points and see how you can help
Make them part of the design process, this demands more time from them upfront but in the long run this is more efficient.
Let go of the ownership of the design and involve the team in building the design.
Slides from my talk-