Site icon Shine Technologies

Development & Design: Bridging the Gap

TyneBridge_05

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:

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:

For UX designers:

For developers:

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:

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:

Conclusion

So, what did I learn through this process?

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.

Exit mobile version