Development & Design: Bridging the Gap

16 Oct 2015 Development & Design: Bridging the Gap

For over a decade, I have been working with developers, business stakeholders, and users to create digital experiences and/or services that are designed to inform, inspire, and entertain. While creating these experiences I have noticed a certain lack of understanding between software developers and UX designers. In this post I’ll talk about strategies I’ve used to bridge this gap.

The ‘Us and Them’ Mentality

Traditionally, UX designers have collaborated with business stakeholders to resolve business and user needs by creating digital experiences, then passed solutions ‘over the fence’ to developers for development estimation and/or review. The process often looks a bit like this:

This ‘Us and Them’ mentality means that the transfer occurs towards the end of the design phase. This has a couple of consequences:

• UX and business have had minimal understanding about technical parameters
• Initial development estimates need to be revised
• Redesign of UX solutions and therefore a compromised experience for the customer
• Development feeling pressured to deliver on time and on budget

So, what’s the solution?

In 2012, an opportunity arose to redesign a core business site for a multi-million dollar telecommunications company in Melbourne, Australia. Working within an agile environment, we couldn’t afford to take the risk of designing something of that size without delivering an optimal experience for the end-user and business.

To address this risk, we took a more collaborative approach to the process, as shown below:

Providing the opportunity for more frequent open discussion allowed developers, UX and the business team members to share ideas and voice opinions earlier in the process. This resulted in multiple beneficial outcomes for each project team. Specifically:

For the business team:

• A wider breadth of ideas
• A wider understanding and appreciation of UX design and its value to a business and users
• More assurance the project would be delivered on-time and within budget with more accurate development estimates
• Increased knowledge of development technologies

For UX designers:

• A better understanding of development technologies and their possibilities and limitations
• A wider breadth of ideas through all phases of the design lifecycle, we were able to push more fluidly the boundaries of design concepts
• Ultimately, a more consistent experience for end-users

For developers:

• A greater sense of ownership of the outcome, creating a better product for the business and end-users
• A wider understanding of UX design and an increased appreciation of its values to a business and end-users
• A stronger team culture, with developers feeling more valued by the business

To enhance this collaborative process, I created a ‘Design Wall’ for socialising design concepts to the entire project team. The aim was to promote design-focussed thinking from the start of the process, whether it be via wireframes, prototypes, or visual designs. Everyone was encouraged to give feedback, whether it was face-to-face, post-it notes stuck on designs (for the less vocal team members), or via hand-drawn design concepts. We also held daily stand-ups at the design wall, where all aspects of the project were discussed openly.

Additionally, from the start of the project, developers, business analysts, and stakeholders were invited to participate in ‘Project Design Workshops’, allowing the entire team to contribute to the design direction of the project.

The development phase also presented its challenges. Chief amongst this was overcoming the normal practice of ‘throwing things over the wall’, ie, designers spending months crafting digital style guides and then expecting developers to apply them accurately to each element of a UX solution.

After some trial and error we found that using a limited set of digital style guides in conjunction with hand-annotated screen design printouts worked best for the team and produced the required outcome. Some of the benefits included:

• Allowing guides to be created quickly on a feature-by-feature basis. Designers didn’t require days or weeks to create style guides.
• Allowing traditionally back-end developers to gain better skills with front-end development, with mentoring from designers
• Creating stronger relationships between development and design teams
• The design and development teams learning more about their respective fields of work
• Making change-management easier, which in-turn was financially beneficial for the business

Probably one of our guiding principles throughout the process of using style guides and hand-annotated screen-designs was to ‘Review a Lot’. We also noticed that developers learnt more about UX design and design principles, which enabled them to help the designers to maintain the accuracy of the designs.

But what happens when teams are separated geographically?

Where possible, teams should try to be in the same location – but this is not always possible, especially in scenarios such as consulting/agency work. Here are a few tips:

• Organise regular catch-ups between teams. For example, a design wall located at one location where teams meet for a daily stand-up.
• Provide opportunities for developers, designers, and wider business teams to still conduct design workshops
• Review a lot, face-to-face. If this is not possible then review via digital methods, i.e. Gtalk, Skype and Messenger.
• Documentation is essential

Conclusion

So, what did I learn through this process?

• Designers should have better understanding of development technologies and their possibilities and limitations
• Developers and UX designers talk in different tongues – working more collaboratively allows for the development of a common language
• Everyone should have opportunities to discuss their ideas
• Developers and designers should communicate more through the design process
• Patience is key; sometimes design is not a scientific art
• Designers and developers need to review a lot
• With help from designers, developers should understand the basic design principles
• All developers can be front-end developers with the help of designers
• Developers and designers are not really that different

All in all, I think it’s important to keep in mind that, within a product development process, teams should not be afraid of change. Expectations working from project to project will evolve, sometimes requiring a change in how we work together. The most critical thing to remember is that the ultimate goal of any project is to create a great product that end-users will come back to, again and again.