Skip to content

Communication — The app development tool that you cannot download

Authors: Natasja Toldam, UX Designer and Jacob Nyquist, Digital Designer at Jayway in Copenhagen. They are both part of a company-wide mission in order to create the best collaboration between its inhouse designers and developers.

Have you ever found yourself in a project, where you wanted to implement (what you thought to be) a crucial design element, but then found it to be put in the bottom of the backlog by the developers? Communicating the importance of a design element can be a struggle — even in the most experienced teams.

In Jayway, we pride ourselves with the great communication that we have between developers and designers. This topic is part of the foundation for our office, but we are always working to improve and communicate better, both in the project we are working on, as well as after a project is handed over to the client.

One of the things that we have found to be working very well, is to include our developers early on in the creative process. If we are running a design sprint or concept development workshop, it is expected for the developers to be a part of it. We believe that an early and continuous collaboration between design and development is the key to a better and well thought out solution for our clients.

Therefore we found this topic particularly interesting at this year’s ADDC Conference in Barcelona, where we were fortunate enough to hear Sara Cambridge from Google talk about how they work with collaboration between designers and developers while developing Material Design.

Her insights were based on a study she conducted amongst designers and developers, both inside and outside of Google. In her talk, Sara managed to communicate the different aspects of collaboration between designers and developers by using visual representations of graphs and diagrams. In the end, our biggest takeaway was to keep improving the processes that we already use for collaborating at Jayway, by being curious about how to integrate the design we have created, in the development. Furthermore, she confirmed our strategies of always discussing, asking, advising, sharing and supporting each other throughout every stage of the product development process. This is an ongoing focus for us and the topic “collaboration between designers and developers” in Jayway is under constant improvement. Is it the same for your company? Otherwise, it should be!

Coming to ADDC, it was relieving to see that we are not the only ones who are perplexed about this topic. If everyone else had solved it, there would not be a need to talk about it. But there was. And people were eager to find their own solution by getting inspired from how others are trying to tackle it.

One subject of conversations between designers and developers is the implementation, and communication of the importance, of the subtle details. All designers can probably agree that there is always room for improvement in their design (even if we weren’t constrained by time and money). That is how we get better as professionals; by insisting on improving and learning from the mistakes done in our previous work.

It’s no secret that designers like to experiment with design choices. Sometimes you just don’t know how something is going to look until you try it, and then try it again (and ok, maybe one more time) in a different shade of blue or with even more white space.

Maybe a gradient would make the app look lighter? Or what about the corner radius of those cards? These are changes that might not seem relevant or important to most people, but as designers, it’s our job to combine all these small details in order to enhance the full experience. Working in an agile scrum environment, these changes can often get considered to be ‘less important’ and end up in the bottom of the backlog, having the designer screaming from the top of his/her lungs (maybe just on the inside though). This is hopefully not a cause of evil developers, but rather an side-effect from old working techniques like the waterfall model.

So how can we update these old habits to match the more dynamic workflow that we have in this industry today?

From a implementation perspective, it’s always better to have a design that’s fairly close to the native platform guidelines. This can on the other hand be a limitation for the creative work.

Google decided to release a new version of the Material Design at Google I/O earlier this year. Material Design has previously been criticized for being too restrictive, which resulted in most Android apps looking too similar. This is what the new Material Design is supposed to correct by making it easier for designers to design within the framework, but still being able to customize the design to their needs.

Following is a quote from Google’s release of the new Material Design:

It’s no secret that designers like to experiment with design choices. Sometimes you just don’t know how something is going to look until you try it, and then try it again (and ok, maybe one more time) in a different shade of blue or with even more white space.

This misalignment is something that Jolanda Verhoef, Lead Developer at coolblue, also has tried to improve by implementing living design systems for the coolblue apps. Jolanda wants to think about designers as part of the development pipeline, making the designs assets more accessible for everyone working on a project. This is definitely something that would help solving the previously mentioned problem with ‘small changes’. The optimal solution for this would be for the designer to be able to update assets or change colors within the code and without any involvement from the developer (apart from fetching and pushing the changes). This has previously been a no-go since many designers don’t have the necessary coding skills that this requires. But by using the living design systems, more of these small, but important(!), improvements would then make it to production, creating a more enhanced end-product.

Prototyping is an essential part of the communication between developers and designers in Jayway and as it is right now, we are using multiple prototyping tools to create a more coherent collaboration. Invision is used to show how we expect the structure of the app to be implemented. Principle and After Effects shows the animations we are hoping to get implemented (truth is that the really nice, small things are icing on the cake, but is also what makes the user experience more special, and essentially what can make or break an app rating). We use Zeplin as a communication tool as well, for the developers to find information about icons, dimensions, colors etc.

1_GUFvECKXTGFzIneEiXOr5w.jpeg

John Sundell, another speaker at ADDC had a talk called ‘Prototype Everything’ where he crystallized the importance of rapid prototyping in product development. Both for design and code.

John’s four cornerstones of quick and efficient prototyping were:

  1. Constraints (removes the pressure of perfection)

  2. MVP’s (Minimum Viable Prototype, and not product!)

  3. Modularity (Being able to reuse components)

  4. Creating tools (Streamline your workflow)

By prototyping as early and often as possible, we can make sure that an idea or concept is understandable for the user, and it will give the developer an idea of the direction that we want for the app. It is a valuable way to manifest our thoughts of the solution, and it allows us to move faster towards the goal in our design process. There are countless of ways to make a prototype, but for every prototype that we create in a project, we are getting closer to the best possible product. For further development, it is then possible to learn from past mistakes and push the boundaries for the next project.

All of these tools have one thing in common. They won’t work for a second if you are not also communicating between the professions. Communication is key, and this is how we understand each other’s choices and ways of working — which of course should go both ways between developers and designers.

We want to give a big thank you to the ADDC Conference, for highlighting the very importance of having a conference that mixes both designers and developers interests. After all, even though we might sail in different boats, we are on our way to the same destination.

The boat “party” at ADDC 2018 ?