A couple of weeks ago, Matt and I had the chance to speak at Digital Shoreditch 2015: sharing ideas about creating the best user experiences with responsive web design. I explored how we can build better communication between development and design teams, avoid misunderstandings and the consequences for the final product.
Background
Over 20 years ago, I started as a graphic designer for a small advertising agency. We painted and built signs for shops and buildings before everything was printed, with a little bit of branding and collateral design. After a few years, we began digging into web design. I became a front-end web developer in 2003, and never looked back.
I now work at Cyber-Duck, which specialises in responsive web design, user experience and technical development. Like many modern agencies, Cyber-Duck has a very dynamic environment, with new ideas, techniques and technologies available to explore constantly. It can be a challenge to embrace change quickly, experiment with what’s out there, and update our process accordingly.
The 'Dividing Wall'
Given my varied background, I aim to work closely with everyone, throughout all stages of my projects: from UX and design decisions, to delivery and ongoing support. This close proximity means I can observe what everyone is doing, and how are they doing it. But, most importantly, I can clearly see how everyone is interacting with each other.
From this, I’ve realised the specificity of our jobs have encouraged us to build a ‘dividing wall’. This wall grows taller, as each new trendy typography comes out. It grows thicker, with each new Gulp workflow published on Github. In the end, it makes us feel further and further apart.
After working for so long on both sides of the imaginary wall we’ve created, I’ve realised the more we see it, the bigger it gets. It’s kind of like that anxious feeling you get when waiting for something to happen. Every time you look at the clock, it seems to tick more and more slowly. The same happens with this wall. Every time we don’t know how to ask something, every time we don’t know how to speak to someone, the wall grows a little bit taller.
So, we have slowly created a communication gap that must be fixed. The gap exists because people in different teams understand things in a different way. They can even value each other’s work differently.
When communication is broken like this, everybody can start to assume things. Like, designers can think: “I’m just going to put all this content here, and developers will find a way to code it” or “…it doesn’t matter if I put this box here instead of there, does it?”. Too often, assumptions bring out unnecessary complications, which lead to delays and frustrations. And, that wall will grow bigger.
Under an Agile approach, the process of creating a new website (or feature) for most agencies goes like this: moving from initial research and information architecture, to creating sketches or wireframes, and then the visual design. This is immediately sent out to the client for review and sign off. Too often, this happens without any input from the development team.
How Can this Affect Responsive Projects?
Pre-responsive design, website production had distinct communication problems: like proposals versus enquiries, specs, feature creeping etc. There wasn’t so much talk about the gap between developers and designers.
Responsive design brings a new challenge to the table: uncertainty. We all know how designing and developing for the uncertainty of different screen sizes and input methods can be stressful. Trying to explain how an interface should look across a wide range of screen sizes is hard. Now, design is not the same as assuming all desktop users will use a mouse; we have to create interactions for uncertain inputs, like touch screens, keypads, voice commands or even things that react with the way you look at them!
What happens when this uncertainty is added to our communication problem? We start adding things we believe will solve some of the issues: libraries, polyfills, and plugins to support touch, to support media queries, or responsive images, etc. The consequence of these complications are the impacts on performance, time and budget.
Having to solve problems at the development stage could be avoided by discussing challenges across teams, to find the best solutions together. By reducing the gap.
Internet data analysts have pointed out how the size of websites has been growing more and more in the last few years. At the same time, opponents of responsive design claim that the approach makes sites bigger and slower. I believe these issues are not responsive design’s ‘fault’ – it is a communication problem.
Hanging on in quiet desperation is the English way.
This quote from Pink Floyd’s song “Time” refers to the English character – but it’s pretty common to find the same across many cultures.
What Can We Do About It?
Learn the language other teams are using. Using a little bit of the terminology used by everyone helps improve communication, as all parties will have a better understanding of what others are doing.
An easy way to get started is creating a cheat sheet or glossary with quick descriptions of the terms used commonly by each team. It could even be given to clients, to help understand your process. I promise, it’s not too much to learn and isn’t difficult in practice.
Designers can get involved in the building process. They could check with developers often, reviewing how are they building the things they have designed. This gives designers an idea of how design decisions can be implemented in code, and what it takes to achieve them. A beautiful design that is too slow to use, takes too long to load (or to build!) can negatively affect the performance of the product, or its budget.
Developers should aim to understand the design decisions. It can be too easy to disregard something they don’t know why is in the design. This understanding gives value. Otherwise, building something fast that performs well, but is not usable or enjoyable does not achieve a good user experience.
Ultimately, when designing something, it’s important to know the consequences or ‘cost’ of this feature. Cost can be affected by development time, budget, page load and performance.
Using time to think about how a design element will have to be developed reduces problems and time during implementation. During all stages of the project, sit together to review status, solutions and implementation. Collaboration is key to achieve a good balance of UX, design and performance at the end of the project.
Conclusion
We live in a time that has been called the ‘age of communication’: we’re always connected. We have all kinds of devices that are supposed to help everyone to communicate better. And yet, we keep assuming, misunderstanding and staying quiet when issues arise.
For millions of years, mankind lived just like the animals. Then something happened which unleashed the power of our imagination. We learned to talk…
Stephen Hawking
The ability to communicate with each other is one of the most precious things we have as human beings. We need to use this ability to improve the way we interact when building web solutions.
We need to get rid of this idea we have that we’re so different, just because we’re working in different teams. We need to realise how important it is to talk more, understand more and work closer together. Because we’re all here together, building the same web.
Here are the slides:
