Bridging the gap between design and development

So a while ago‚ I sat back and looked at the app development process we had. The main issues within it seemed to stem from communications; but looking deeper it was more so the barrier between Design and Development. So I plucked it apart and found out the issues listed below.  

Designers don’t code

“You should code!” 

Well most don’t‚ and I’m a strong believer that us designers shouldn’t have to know code for a seamless transition in an agencies practice. We make decisions upon the look and functionality and visually implement them into a digital solution. Of course‚ if they do it’s good for them but I don’t see it as strictly binding. They should instead learn how developers work and how they think to make the collaboration smoother. Devs make decisions that will shape the outcome of the designs and implement them. We’re all problem-solving‚ but specialise in different ways of doing it. There is no time for a Jack-of-all-trades in the agile environment.

The learning curve of being able to code at the level the dev-team is huge. These guys have been doing it for years‚ have undergone bachelor and masters degrees in it‚ and have more knowledge about the fundamentals of it than a fresh faced designer could grasp in years of studying it. And in that time you’re trying to learn it‚ your design skills aren’t being nurtured.

We think differently

We design in visuals‚ not in percentages. Whilst we do use grids‚ and off the shelf components‚ we don’t be thinking entirely about screen sizes. Sure we design for the iPhone 4 as well as the 7‚ but not with the way we should and not in the way our devs want us to. The design needs to become fluid and responsive. iOS designers need to adopt the Android relative layout principle to allow our devs to create one piece of code that accommodates all screen sizes — through percentage based design — and not force them to have to write several pieces of code to accommodate your different designs for different devices.

As a rule of thumb‚ we (hedgehog lab) design iOS apps for the latest OS and the one before‚ so right now we’re designing for iOS 10 and iOS 9. That doesn’t mean iPhone 7 & 6. No one designs for a 4s as their main screens — and quite rightly — but we have to support them if we want to reach all of our user base — devs understand this‚ designers often shunt it. It’s often left out because of its unpopularity in comparison to the other models — but the iPhone 4s still has 18‚100‚000 active users according to Eddy Cue — that’s a shit load of people.

We are stubborn 

As designers‚ we can see in our mind how we want certain elements or screens to behave and expect the finished app to mimic that exact vision. However‚ the issue I often found was I couldn’t communicate it well to other designers let alone the devs‚ and yet expect my code-savvy colleagues to understand what I want with no real documentation. I’m asking them to mind read transitions between static art-boards that look nothing alike with no inclination as to what I want. Often this was down to poor or a lack of communication between departments. The key to multidisciplinary collaboration is communication.

No know how

It is up to us designers to know what is possible and what is not‚ its no good in this fast paced agile world to knock up 10 iterations of a design until you get something possible — learn from your dev team what you can/cannot make happen within the parameters of your project bearing in mind time‚ cost and resources available. The world of app‚ mobile and digital solutions is forever changing. With that‚ comes a need for self driven education and constant learning of new ways of doing it. That falls on us designers‚ it is our job to know whats possible‚ to then create a design and get it sense checked by development‚ not rejected by them. I wrote a blog titled ‘How I stay sharp’ which lists my methods of keeping on top of the design practice and theory.

Lack of planning

I’ve been part of a team hit before by a fast approaching project. As soon as it lands a client is demanding results with very little time to plan against the project. The issue there is you will face problems and have to track back constantly. So all in all‚ it takes longer than if a project started a week later to allow a thorough end to end plan. By not planning projects correctly‚ we see key moments such as the time needed for handover being forgotten‚ or missed.

Furthermore when we don’t plan and a project isn’t thoroughly vetted‚ negative feedback loops between design and development can take place where questions that should have been answered at the start of a project occur half way through.. A lecturer back in uni said to me once “You don’t spend £20 on a meal without planning what you’re going to get first‚ so don’t spend £200‚000 of client cash without making one either.” Wise words that I carry and cherish to this day. 

.    .     .

So when after I highlighted the crap between design and development.. I then came up with the fixes to implement into our team to help bridging the gap between design and development.

Step up your knowledge

We as designers have an abundance of resources — including our dev team — at our disposal to learn from. Our job as designers is to ensure that the project utilises all these resources‚ best practices and technologies and create the best solution for the problem our clients are trying to solve.

Just small pieces of knowledge here and there can speed up your process massively‚ things like stock v custom elements — knowing that stock elements could save 2 days worth of dev time instead of creating some crazy animation when a simple transition will do. Sometimes it needs to be custom‚ that’s fine‚ just evaluate and ensure that stock can’t be used especially for MVP purposes.

Don’t learn code‚ learn what it needs

Like mentioned before‚ there is a huge learning curve involved in becoming a developer. Why waste your time trying to become one‚ when you can simply learn what you need from the vetted and certified teammates you already have sitting at the desks next to you? Learn from them what they need to do their job well and facilitate it. This ensures bridging the gap between design and development.

Multidisciplinary collaboration & communication

Building from this‚ as you design‚ you need multidisciplinary collaboration to achieve success. Get it vetted by the people who will have to build it and by the people that will have to use it. Our greatest asset is having user centric input. They see your designs in a different light and can reveal where your designs could be improved. Ensure you’re engaging with your wider team and asking questions on what is possible from the earliest moment is what will lead you to a successful project.

Planning

Sounds simple‚ but getting a well oiled project that runs smoothly‚ with no hiccups is near impossible. But what’s going to make a difference is all the micro factors in between. setting up touch points‚ knowing what tasks have to be done by when‚ having a fully fleshed out plan of an app that has all the appropriate departments involved in it. By planning and getting the work done right first time‚ it allows for seasoning which is where we can include custom animation.

The key deliverables

These are what I label as the bare essentials of the handover to my devs. They were defined and constructed in collaboration with our Lead Developer (Sam Miller)‚ Technical Architect (Craig Tweedy)‚ Chief Technology Officer (Alan Morris) and Chief of Design (Ray Clarke) .

[1] Fully fleshed UI. Sketch file built using AutoLayout and the Atomic Design Principles.

We recently had discussions about the issues of the designs being given to the dev team. It wasn’t anything to do with the quality of the designs that were the issue‚ but the way they were constructed. Our lead dev explained what he and his team saw‚ and the information they need to code effectively and efficiently. In particular he raised a point saying we need to be aware of Auto Layout and how that works. Luckily‚ theres a plugin for that. Auto Layout is a sketch plugin that allows you to see your designs at all screen sizes‚ and turn pixel distances into percentages — these values can then be passed onto the dev team who can create one fluid piece of code instead of different individual screen sizes — perfect. 

Atomic Design in short is building a UI through the mind of science‚ looking at each element as if it were atoms‚ molecules and organisms. A search icon is an atom. A search field is an atom. A search filed and a search icon together is a molecule. A search icon and a search field together inside a top based navigation bar is an organism. And so on.. 

Developers build with this principle in mind. The best way to implement this methodology into your design work is by the use of Sketch Symbols. They’re so powerful in speeding up your design time and allow changes to be made to a thousand screen designs and only change one element. This again‚ is a how devs like to work — they build repeatable components which is exactly what Sketch Symbols are.

Cultivating a design built on the fundamentals of Atomic Design theory‚ and Auto Layout responsive design will allow your devs to hit the ground running — and I promise you’ll be in their good books until you show them the custom animation you’ve made..

[2] Style Guide

Though it seems redundant when you hand over a fully fleshed out UI file‚ the style guide is for quick reference and in all honesty is probably used more than the fully fleshed UI by devs when building components. It should house all your colours‚ typography‚ iconography‚ call to actions (CTA)‚ shadow depth‚ ANY repeatable or custom element of your design goes in. 

You can build a style guide in Sketch in 3 seconds that is ready for your devs to use immediately. Download another plugin called Craft by Invision. then simply hit CMD + Shift + C. If you build your sketch file using the atomic design principles‚ this works even better as it gets rid of human error when duplicating common elements.

[3] Fully interactive‚ end to end prototype

I feel the only way to bridge the gap in explaining the behavioural part of a design comes from prototyping — especially using something such as Principle that allows for precise interaction.

Static art boards are simply emotionless‚ one prototyped transition could save hours of trying to describe in words to a developer how something should move. The saying a picture saves a thousand words is true‚ yet a prototype saves tenfold. 

We create these using Principle which for me is the most powerful tool (past sketch) in my design arsenal. It allows for me to create an end to end‚ animated‚ fully interactive prototype showing every aspect of an app and with its direct plugin to sketch‚ I can hand over a prototype that looks and functions exactly as I envisioned.

It does come with quite a steep learning curve if you have never before looked into prototyping software or used software such as Adobe After Effects that is time line based‚ but once you’ve got the hang of it‚ it is remarkable. Further more‚ it only allows you to edit attributes and create design flows that are possible to build from a dev side‚ helping again get rid of communication loops between design and development.

The beauty of it is I can create a prototype that to the untrained eye (users and clients) it looks‚ feels and behaves exactly the same as a final build. Following on from this it breaks down communication barriers across the field. Not only do you give devs a better understanding of the project‚ but you give your client something much more tangible than a set of screens. Your client is then able to not only understand and visualise it better‚ but also put the prototypes out to direct users‚ or possible investors. A well designed prototype can look‚ feel‚ interact and behave exactly the same as the real product and yet costs the client no development time at all‚ at most it costs an extra week from a good designer.

In terms of direct impact to users‚ prototypes allow us designers to see user behaviours and their desired path to success. From studying it‚ we can take that information and embed it into our designs to ensure that we’re capturing and designing in the best way for our users before the cost of development. We’re creating digital solutions that are of second nature to our users.

---

This was part of a talk on the Power of Prototypes given at Sunderland Digital.