This is part twp of a two part series. Read part one.
Working closely with other designers gives us the opportunity to learn from their experience and enhance our own: how do they present their work to clients? What tools do they use to keep track of project milestones? How do they make sure to stay on budget? Not shying away from collaboration can introduce you to some new friends and improve the quality of your work. The more different the designers, the bigger the challenge and greater the potential to broaden your horizons.
In the first part of this series we’ve looked at the steps that must be taken at the beginning of a project to ensure that a successful collaboration is possible later on. We set the foundations of our team dynamic by determining clearly defined roles and explained how each member’s contribution will work towards the common goal.We setup a rough project plan. Finally, our team agreed upon collaboration tools and other project conventions.
Our fearless UX-men team is now ready to dive deeper into their quest for a rewarding user experience. Their team dynamics will be put to the test through rounds and rounds of feedback sessions.
Will they survive to design another day? Read the epic conclusion to find out!
Design superheroes should focus on their role and give others space to do their thing. Throughout, teammates should keep each other updated on their progress, the approach they’ve used, the research they’ve completed, etc. Jon Whipple explains the benefits of keeping research (used here in a loose sense) pervasive in his article What Designers Know:
Research functions as a lubricant, reducing friction around contentious issues and providing consensus among designers, developers, and clients. The upshot is that a clearly defined result, commonly understood facts, and relevant data make design discussions easier.
In sum: short, daily meetings keep everyone updated when work is done in parallel.
If these aren’t a good cultural fit, consider handoff meetings. During a handoff meeting the person who just finished a portion of a project (the information architecture for instance) presents her work to the rest of the team. She explains what she learned from the client and her research, and gives an overview of the process that she followed. This gives the team the opportunity to make suggestions and ask her questions.
Afterwards, she presents her work to the client and explains that she’s ready to pass it off to the next team member to continue the work. In Whipple’s words, handoff meetings: “distribute research throughout the organization.” This allows everyone to feel equally included in the whole process and also helps teammates better accept and respond to criticism.
Unless they don’t, of course
The ego battle
Despite your best efforts – in the midst of the combat – the much-feared moment inevitably arrives: the ego battle! He’d like it darker, 3 pixels to the left, and with smaller text. You’d like to crop his head off. Relax! First, listen carefully to his point of view. Practice active listening. You’ve spent 100hrs perfecting this and he hasn’t, so you’ll need to explain your ideas in terms that he understands.
Communication skills are a great investment for any designer. Another valuable investment is an “invisible armor.” As Melisa Angulo-Javier explains, UX-men tend to be empaths. While this quality can help us relate to the end users, it also makes us further inclined to take criticism to heart. There are a lot of advantages (both personal and professional!) to being able to momentarily distance oneself from one’s creation, not the least of which is that we tend to make more rational decisions when we are cool, calm and collected.
You’re using all the right arguments to defend your decision and your teammate is still not moved by your discourse? Take three deep breaths and consider that you might be wrong. Yes, even a hero is wrong sometimes!
Ok. You thought about it. Still don’t agree? Agree to disagree and seek a middle ground. Is there a way to validate the options with the client or the end-users? A/B tests are a great way for choosing between two solutions. You can also make a temporary decision and test later on to see if your/your colleague’s hunch was right. For example, if I want to validate that users will notice my “buy now” button despite it being on the small side, I’ll devise a test where the user must add the product to the cart. If most of my test users find the button without a problem, then the design is on the right track.
No design is perfect and no UX-man can predict user behavior with absolute certainty. Simply document questionable design decisions throughout the project and you’ll have a short-list of objectives for the next round of design.
What if you were on the other side of that ego battle: the one giving criticism? Here are a few ways to ensure your feedback will be well received:
First, remember that you are not the universal measure of how good or bad something is. Temporarily trade in your superhero persona for a more humble character and show respect for your teammates’s point of view.
Second, reflect on the type of feedback you want to give/receive. As mentioned by Zenhabit’s Tim Samoff in his article How to Give Kind Criticism, and Avoid Being Critical: “using criticism to help someone improve, to see a change affected, or to contribute to a discussion, are all good reasons for doing it.” If your reasons for delivering criticism include: to hurt someone, to vent frustrations, to boost your ego, or to challenge others you should reflect on the option of keeping quiet.
Third, employ tact to make sure your criticism is well received. Use kindness to show that you are empathic to the challenges faced by your hard-working teammate. If your tone of voice says “attack,” the person receiving the feedback will likely adopt a defensive stance. A great strategy is to focus on making positive suggestions. In other words, suggest ways in which the work can be improved and the rationale behind it: “If we increase the text size, these long paragraphs will be easier to read,” instead of simply pointing out what’s wrong with it: “The text is difficult to read.” In general: good suggestions tend to be more specific, which ensures that they are actionable.
The motto of every successful team should be to take advantage of each member’s skills and to help improve their contributions, not disempower them. A happy ending is possible. We just have to put our aside our egos for the good of the project.
This is the walking off into the sunset part. The mission is accomplished. Users are happy. The world is safe.
Together, you’ve faced the challenge of respecting one another while working towards a common goal. You’ve mediated heated debates and ensured everyone’s contribution was appreciated. You’ve survived every team meeting. Now’s the time to reap the benefits of an accomplished mission and strengthen the bonds you’ve just created.
Before we end, we need to bring our design superheroes together one last time to celebrate and reflect. A project retrospective is an often-overlooked step in the healthy life of every superhero team. A retrospective is a meeting held after the delivery of a milestone or after the completion of the entire project. Originally found in projects managed using SCRUM development methodology, this type of meeting is a good addition to any venture. Retrospectives gives every team member the opportunity to express what he thought went well, what he thinks could be improved and what he’s learned from the project. The team effectively brainstorms together on ways to improve team-dynamics and the project plan.
If you’ve made it this far, you’ve surmounted difficult challenges and bested feedback-wielding foes. You’re likely dying to share with the world the incredibly awesome work you’ve just done. Just don’t forget to share the credit…there is no “I” in “UX teamwork,” after all!
The author wishes to thank Kent, Dorothée and Lindsay. They’re continuously teaching her the meaning of a great design team!
During my years in an agency, I've seen the spectrum of tool experimentation. I've heard passionate user experience designers argue in favor (and equally as often, against) Axure, Balsamiq, UXPin, Invision, Photoshop, you name it. We've tried it. Usually, the outcome is something out of Goldilocks and the Three Bears: the tool is too robust, or too simplistic, too slow, or too buggy, and no one's happy.