Software development is by its nature a very creative process. Obviously graphic design is an art form, but there is also an art to the technical architecture of a project, the coding style, the way you test, and the interaction design. Those roles are filled by multiple people on a single project, each one bringing their own perspectives, style, and tastes to the visual and technical design of a product.
With that many artists in a room together, there is bound to be conflict. If you manage it well, it’s healthy conflict that results in a better end product. If you foster the wrong types of conflict, then it will result in a team with no teamwork, bad feelings, and a worse product.
Here are 7 keys we have found to ensure that your interaction designers, visual designers, and developers are working together rather than against each other.
#1 – UX leads should have development experience
Google the phrase “why everyone should learn to code”, and you’ll see a lot of debate about who needs to have programming skills in the modern world. One thing is clear, that everyone benefits from having at least a little knowledge of how software development works.
This is particularly true with User Experience leads because when you design the UI and interaction patterns of an application, you are also determining a lot about how the technical architecture of the application must work too.
Our UX lead Mariana started out as a software developer, but realized how much she loved solving interaction design problems. In the video below she talks about that epiphany she had – that even very technical people can have a hard time understanding poorly designed interfaces. That inspired her to go on to a Master’s degree in Human Computer Interaction.
Mariana Lopez on why she got into UX design from Arin Sime on Vimeo.
That UX training is certainly valuable to her, but what’s also very valuable to our team is that her previous experience as a software developer means she understands the challenges a developer may have in implementing her ideas, and she also can call “bullshit” if a developer pushes back on her designs. Her training in computer science helps her to know when to push harder on the team, and when to back off. And they respect her more because she has that knowledge.
#2 – Designers should be HTML developers
Here’s another fun term to Google: “is html a programming language?” While you can debate whether implementing a high quality HTML and CSS framework is true development or not, there’s no debate that it’s important. And not everyone is good at it.
If your designer can only create things in Photoshop, then you should invest in having them learning more HTML and CSS skills. They don’t have to become a developer, but it’s incredibly helpful that on our teams our visual designer takes the first stab at implementing the HTML and CSS of his designs.
In this way, Daniel ensures that the project starts off with a best practice CSS implementation and structure, and he can help developers with front end bugs as they migrate his HTML mockups into the larger application code base.
#3 – Everyone should be comfortable with iterative work
Not everyone is cut out for agile teams or the iterative work that they require. Some people may be very talented at design or development, but they are simply not comfortable with working in small chunks. They may have a hard time with showing you a half complete design for your feedback, or doing a demo of code that is not fully functional.
If your team is making even a pretense at the speed and flexibility of agile work, then everyone on the team must be comfortable with working in iterations. That means the UX and design leads must be comfortable with designing the website a piece at a time. It’s still okay to do a lightweight information architecture document upfront, or lightweight process flows and wireframes, just like it’s okay for a developer to do a lightweight technical architecture diagram before coding. The key word is it must be lightweight, quick, and subject to change as more information is learned not only from customers, but also from your teammates.
If anyone on the team, perhaps especially a design or UX lead, is not able to work in small pieces then harmful conflict is inevitable in the team.
#4 – Developers should be empowered but respectful
Just because you have a User Experience expert on the team doesn’t mean developers should have no opinions about the placement of buttons. The UX lead should have final say in this area, just like developers have the final say in how they code the application. Developers should respect that final authority lies with the UX lead for interaction design, just like they must respect that the final authority for work priorities lies with the customer or product owner.
But developers should also be empowered enough to offer their own ideas and improvements to what the UX lead comes up with. And the UX lead has to be able to take feedback from others without a U or X in their title with grace and an open mind.
#5 – Use Sprint Zero’s effectively
Just because you’re working in an agile fashion doesn’t mean you can’t have any up front design. As I said before, it must be lightweight.
In agile teams, this short and lightweight up front process is often referred to as “Sprint 0.” In our team, that means a couple things:
First, the entire team and customer agree on a “walking skeleton”. This is a very simple path through the system architecture that allows you to test interfaces and external API’s, as well as try our new technical ideas or code libraries. It’s also a way to test the high-level process flow that the product will build. The end product is not usable by customers, and has no design or attractiveness associated with it. It’s just a technical prototype, and the developers should focus their efforts on building that in the first couple weeks of a project.
In parallel to that, the UX and design leads can start working on the first round of more detailed design artifacts like wireframes and HTML mockups. That way when the developers complete the walking skeleton in a week or two, and they are ready to begin building the real product, the design team will have had time to complete the first round of mockups and graphic assets.
An effective Sprint 0 will be a collaborative design session between UX/design and development, and at the end everyone on the team will have had their voice heard.
#6 – Use a 3 Amigos process
A 3 Amigos meeting is a pre-planning session for Scrum teams where the developers, testers, and the customer get together to have discussions about what items will be planned for in the next sprint. The team is not committing to the next sprint’s work yet, but this is an opportunity for them to ask the customer or Product Owner for more details about upcoming work.
These meetings are also the perfect opportunity for UX and design to present their wireframes and mockups to the full team for what they think should be worked on next. Holding these meetings every sprint helps the design team to build a cadence that is one step ahead of the developers, so that both sides feel like they have the information and artifacts they need, just in time.
#7 – Get the team together outside of work
Finally, you need to get the team together regularly in social settings where they can build the friendships and trust that are necessary to weather the more stressful periods of work. If your team is co-located, this can be as simple as taking everyone out to lunch.
If your team is distributed (as our is), this is more complicated and more expensive, but it’s worth it. The video below is one we made about a team building event we had earlier this year, and I encourage you to think creatively and think big about how you can use events outside of work to build the personal bond between design and development that high performing teams need.
Team Building for Distributed Teams – AgilityFeat in Costa Rica from Arin Sime on Vimeo.
It all comes down to TRUST
Ultimately, the only way to ensure harmony and high performance between your UX/design teams and your developers is to ensure they trust each other. That’s not easy, and if they are in conflict now, then be patient. It will take time.
Make sure they understand each other’s jobs by learning a little bit of development or design techniques, are able to work collaboratively in an iterative fashion, and that they have the camaraderie to respect each other personally as well as professionally.
Then you too will be able to build a higher performing team that is a pleasure to be part of.
