Have you ever wondered why your 4th grade math teacher was more interested in how you solved a math problem than if you got the correct answer? Most of us assumed it was because the teacher didn’t want us using a calculator or cheating off our classmates. In actuality, the “Show your work” ask was more about understanding the process you went through and how you made your decisions along the way.
Now, consider the last time you had to present a software or product design. Typically, using the math problem metaphor, we are showing our development teams and stakeholders the final answer and nothing about HOW that design came to be. Just like that math teacher, sometimes the final answer (your design) is met with skepticism.
I had a client tell me that their UX designer would work diligently on a page design for their web site, but the stakeholder team would spend a 4-hour meeting “re-designing” the design, only to end up at the exact same place as the original design. It wasn’t due to a lot of convincing and bartering on the designer’s behalf, the stakeholders (teachers, in this example) just needed to see the process first-hand in order to understand the outcome.
Having the team (stakeholders, developers, QA, as well as UX) included in the design process proves to provide automatic acceptance of design decisions.
Having conversations with the team, specifically the developers about expectations and involvement in the UX design and creative process is crucial. Once we establish how we all want to be involved, it makes planning, tasking, designing and coding easier and more efficient. Just as I enjoy knowing and understanding (to a degree) the technology that will be used to create a product, there are developers and whole teams that enjoy knowing, understanding and participating in the UX design and its process, as well. The collaboration makes me a better UX designer, makes the developer a better coder, and makes the product better for the user.
Collaborative design has pushed me as a developer to do things I didn't think I could do. Working in silos, it is easy to say "that's not my responsibility, the designer will clean that up." On a team where collaboration is valued, there are many opportunities for me to say "oh, I'll make that change, because I know the designer is busy." This relationship works the other way as well — it pushes the designer to make coding changes. We are one team, focused on one product. We are interested in building something awesome, not throwing work over the wall because it isn't our responsibility.
I also appreciate being able to express to a designer when something is going to be difficult to implement. That doesn't automatically make it the wrong thing to build, but it makes us have a conversation about trade-offs. Is there a way we can accomplish the same goal for the user without so much technical complexity? This is an important question to ask and answer when your goal is delivering quality software.
As is mentioned above, a great benefit that comes along with collaborative design is the buy-in of each person in the room because their ideas have been heard, but I want to take a step back and look at those ideas. In my experience, when we talk about a development team, we are talking about a group of really smart people from different backgrounds with different experiences and relationships. Why does that matter? It matters because they bring a perspective to the design that you likely do not have. They think about problems and how to solve them differently than you do. I can tell you that I don't think I have ever walked out of a collaborative design session thinking — man what I had in mind coming into this session was way better than what we worked on in there. No, I am always impressed what can happen if we all stop battling each other and we start taking on the design issues together.
Collaborative design has helped me by having the developers, QA, Scrum Master, and Product Owner involved in the design process early and often so that we can all happily take some ownership in the design that we have chosen to implement as Tom has mentioned. Also, it helps me to always grow as a designer in both humility and technically because the team will often have brilliant ideas together and a shared understanding. This allows me to work best as a UX facilitator to find ways to best collect the teams ideas through design studios and ideation sessions. Whether using a time boxed 6-up 1-up or a whiteboard kung-fu (yes, it is a thing) design session, we can all go back to our workstations with a certain understanding and good feeling knowing we are hopefully on the same page. To me this doesn't necessary mean design by committee as the UX designer does have to make sure the ideas do follow best practices and the living style guide. Finally, I can either share the sketches from the design studio with stakeholders to quickly get feedback on our preliminary ideas or amp up the design mockups or prototypes to the level of fidelity needed to evaluate with users to get feedback to the team. This process has helped me to eliminate design battles and validate designs together.