Effective Team Collaboration
Dorothy Shamonsky, Ph.D., leads UX R&D at ICS. She brings skills from traditional design practices, and experience in UX design/build research environments.
I’m fascinated by the challenge of UX team collaboration, both within a UX team itself and between UX designers and engineers. To be sure, you need an effective working process to achieve good outcomes. Process methodologies such as Waterfall, Agile, Lean and Extreme, each offer a generalized structure for collaborative work to occur. You can then customize a general approach to be more specific to the requirements of a UI/UX project. Obviously how you do that matters a lot.
When adapting a process methodology for UX design and development, my experience has been that drawing on traditional design practices (Graphic Design, Industrial Design) is very valuable. Simple, common sense, tried and true practices can improve the quality of the final outcome; maybe even rescue a project from failure.
Here are four principles of effective collaboration that I’ve applied to UX design and development projects with success. They will even serve you well in the absence of any other methodology:
- Visibility of process, design, and implementation
- Logical sequence of steps
- Ownership in area of expertise
- Good communication habits
Visibility of process, design, and implementation — Enable a truly “shared vision” by making everything easily visible to everyone on the team. This includes the process itself (steps, deliverables, schedule), requirements and design documents, prototypes and working implementations.
A stakeholder’s greatest fear, next to project failure, is that they will not end up with what they bargained for. They need a window into the project to monitor progress, as do all members of the team. Define up front, in writing, the process by which design and development will proceed. Agree on that process, and follow it faithfully. Then expectations are set and unhappy surprises are less likely to occur.
A robust document sharing system is a must. Keep it up to date. Designs can only be understood by the multiplicity of documents that represent them, such as, user stories, lists of requirements, storyboards, visual concepts, wireframes, finished screen mockups, and flow diagrams. By sharing, modifying and agreeing on documents, they act as informal contracts with stakeholders.
Make the working implementations accessible to all those who do not have access to code repositories, so that the UX team and stakeholders can try out the product early, and can review each stage of progress. This may involve developing the code in an order that favors the UI, so that the UX can be evaluated and tweaked early in the process.
Logical sequence of steps — Proceed with the UX design and implementation in an appropriate and logical order. Designing has a logic to it. It progresses from fuzzy ideas, to general concepts, to requirements and guidelines, and finally to specific details.
Need I say it; design starts before implementation. They can proceed in parallel with design staying ahead of development by an appropriate time frame. By working in a logical order, you can get signoff from stakeholders at progressive milestones. The result is that you can build a design from basics to details that you are sure the stakeholders are satisfied with.
It’s not always possible to follow this ideal order, and there can be creative and practical benefits to following a non-logical order. For example, exploring an idea can involve playing out the details in a drawing or developing an early prototype. But too often I’ve seen a non-logical order occur, just because of randomness, lack of experience or bad planning. A stakeholder needs a finished-looking mockup for a demo even before requirements are committed to paper, a developer will be handed the mockup thinking it’s a real design and implements it… work is thrown out and confusion ensues. Working in a logical order is efficient and cost effective.
Ownership in area of expertise — Be clear on who is responsible for the quality and completeness of a piece of work, and empower them to take responsibility for it.
What I’m trying to avoid is the “throw-it-over-the-wall” problem… UX creates a design spec and throws it over the wall to development. Development implements to spec as best they understand it, then throws it over the wall to QA. By the time it’s released, the final product is quite different than the original design for no good reason except misinterpretations and lack of awareness of professional standards outside of expertise areas.
Enable the appropriate professionals on your team to have final say over the parts of the implementation that they are experts in. Graphic designers need to sign off on the visual quality, information architects need to sign off on the menu text and messaging, UX designers should sign off on the usability of the implementation, etc. By doing this, you are getting the maximum benefit from the expertise of your team members.
Good communication habits — Make communicating part of your routine. It’s difficult to collaborate without communicating. Set up regular (daily or weekly) meeting schedules and conduct the meetings even if you think there is nothing to talk about. If everyone reports his or her status, it will almost always prompt better coordination of work. Inevitably, important issues are revealed and have the opportunity to be resolved early. Make sure everyone attends and everyone reports. This is especially important if the team is not all working in the same space.
These four principles are simple but powerful. Granted there is extra effort in having regular meetings, keeping up-to-date document sharing, making working implementations accessible, and getting appropriate signoffs. But in the end, I’m confident that you will find that they reduce risk of failures, enhance quality levels of outcomes, and are actually time and money savers.