Designing for development

Designers can make better products through collaboration, respect and understanding of the development role.

Brilliant websites & apps are seldom the work of a single person. It takes all kinds of people, each with their own specialisms and responsibilities. It’s true what they say. Teamwork really does make the dream work. 

That being said, there can sometimes be friction between the worlds of design and development. To understand why, let’s break down what these two roles actually do.

Designers define what the product is. They make decisions about how things look and behave. These traits are informed by user needs and organisational goals. These decisions are then captured in the form of interface designs.

Developers construct these interfaces, and the systems needed for them to work. They transform flat designs into working code. Developers are also responsible for testing, maintaining and updating the product over time.

It quickly becomes clear that decisions made by designers can have a massive impact on the developer. Designs are effectively a brief for what needs to be built. The designer’s output is essentially the developer’s workload. Whilst a developer-friendly design makes life a lot easier, an impractical one can cause headaches.

A lack of consideration for technical factors in the design process can make the developer’s life unnecessarily difficult. This potential for friction is something we always need to be mindful of. An over-engineered design doesn’t just put a rift between teammates. It can also present huge efficiency losses for projects and organisations.

Designer and developer collaborating together
Getting developers involved during the design process makes for smoother projects and better end-results.

Good things happen when we work together

It should be a no-brainer. Good things happen when designers and developers collaborate. In spite of this, far too many teams don’t consider technical factors in the design process. 

I’ve been witness to projects where the development team were only given visibility of interface designs after they were approved with the client. In other words, when decisions were already agreed. It was too late to provide input, and the developers just had to lump it. Unfortunately, this is a way more common scenario than you would think.

It’s a pity, because a lack of developer involvement during the design process can cause real problems. Even the smallest design decisions can have a massive impact on build complexity. Tiny choices in the interface can result in days of extra development effort. But quite often these complications are entirely avoidable. What if there were other more efficient ways to meet the user’s needs? Alternative options that didn’t put so much strain on development?

Let’s be clear. I’m not suggesting that any designer wishes to spitefully inflict complications on their developers or set out to deliberately over-complicate the product. These kinds of issues stem from a simple lack of understanding around the build complexity of certain features. 

This lack of knowledge is totally reasonable. After all, there’s a reason these separate specialisms exist in the first place. Designers need to be focused on producing the best possible user experience. They aren’t expected to know the ins-and-outs of implementation. But this is why collaboration is so important. 

“Should designers code?” is an age-old debate. We won’t get into it here. There are all kinds of opinions on the subject, and what works for some may not for others. What’s important is mutual respect for each others’ disciplines.

The ability to be humble, and involve teammates in key decisions is an essential trait for any designer.

Collaboration also means efficiency

It’s clear then that designers need to involve developers throughout the process, instead of throwing work over the fence. Working together produces better ideas, and steers us away from poor choices that would cause problems later.

But there’s more to it than just that. Collaboration also helps us make more cost-efficient choices.

The harsh reality is that we live in a world where time is money. All projects have a finite budget, and we must therefore be selective about where time is invested. If a developer’s energy is wasted by poor design choices, we lose time that could otherwise be spent enhancing the product in meaningful ways. We’re all familiar with user testing and QA being descoped because there wasn’t enough time. Well, what if we were more efficient with our time?

UX is often described as the intersection between design, business & technology. That third element can easily be taken for granted. Every feature idea and interface element creates what’s called ‘technical debt’ in our product. The technical debt we accrue represents not only the effort to build features in the first place, but to update and maintain them over time as well.

Venn diagram of UX
UX is the intersection of user needs, business goals and technology factors. It can be easy to take that last one for granted.

When making decisions, it’s crucial that we weigh the benefit we’re providing to the user & business against the technical debt we are creating.

Getting developer oversight during the design process means that we can avoid unnecessary over-engineering of the product. Developers can flag where large amounts of debt is being created by specific features or interface elements. By discussing these, we can potentially come up with better ways of doing things. We can work together to make reasonable compromises. This makes for more cost-effective products without impacting the user experience.

Crafting developer-friendly designs

Designing for development has a practical side, too. No matter how collaborative designers and developers are, there will come a time when some kind of handover is needed. Handover involves the completed interface designs being supplied to the developer, so that they can start the build process. 

It’s the designer’s responsibility to make this transfer as seamless as possible. They need to give the developer everything they will need. Making this transition run smoothly involves using some more functional ways of working, and best practices during the creation of interface designs.

Consistent use of a design system

Fundamental design elements should be used consistently, and be clearly documented. These ‘visual rules’ should apply between all of the screens and states in our product. The design system includes typography, colour and graphical decoration. Not just that, but interface components such as buttons, forms and content cards should be used consistently, too. 

We use the analogy of ‘building blocks’. Website components should be treated as blocks that can be used again and again when needed.

The perfect design should have as many components as is required to engage users and meet their needs… but no more than that. Reusing components effectively and not reinventing the wheel each time makes the build process much simpler. It also helps to keep the product maintainable in the long-term.

Most modern design tools such as Sketch, Figma and Adobe XD offer several features to ensure that design systems are used consistently throughout a project. All of those software tools allow the designer to set global typographic styles, colour palettes, and even create re-usable ‘master components’ that can be used across the file but updated from a single place.

Utilising these design tools ensures that consistency doesn’t drift between screens between iterations. Mastering them is absolutely crucial for every designer.

Not reinventing the wheel each time makes the build process much simpler. It also helps to keep the product maintainable in the long-term.

Grids, layouts & structures

Layout rules form an important part of the overall design system. That’s why every design should use a consistent grid. A grid sets out how content will (and won’t) be organised in a layout. It helps us to set the specific sizing and spacing rules used across screens.

As with all forms of consistency, a grid makes life easier for developers. It helps them to know that new design elements will follow a predetermined structure. Having a grid also helps with forward planning. Other developers and designers who join the project at a later date will have guidelines for how new components should be designed.

As your team becomes used to working together, it may even be worth setting expectations for layouts across your different projects where possible.

For example, at Pixel Fridge we tend to use an 8-point grid for all of our designs. This means that all of the elements in a layout – the content, the margins and the padding – are sized in increments of 8pt. It adds another degree of predictability, with fewer decisions needing to be made every time we start a project.

Due consideration to edge cases 

We all like to design the perfect scenario. Who wouldn’t? Mockups full of content and activity look way more interesting, and they help us to better understand how things should work in the ideal scenario.

That’s all well and good, but when we’re so caught up in the ideal we can neglect the edge cases. It’s during these more unusual situations that the user experience can go awry.

There can be many edge cases to think about in a single product. Here are just a few examples :

  • An error in a checkout form.
  • A ‘0 results found’ page for a product search.
  • A events feed, when there’s nothing scheduled.
  • Layouts that are broken by unusual content. Really long usernames are pretty common scenario.

If the developer doesn’t have designs for these unusual states, they’ll be forced to make assumptions about how the interface should behave. They won’t necessarily have the time or the knowledge to come up with the best possible solution by themselves. It’s also a bit unfair to force developers to solve problems that should have been considered in design.

Oversights like these allow for usability issues to crop up in a product. Great design is all about attention to detail, considering every possible scenario. The designer has a responsibility to plan for these edge cases, and ensure they’re communicated to the developer as part of the handover.

Great design is all about attention to detail, and planning for every possible scenario.

Clear, inspectable design files

Developers will be spending a lot of time looking at the design files, so it’s best to make sure they are well organised. 

  • Grouping and naming elements in an obvious way makes files much easier to navigate. 
  • Images and other graphics should be provided in useful formats.
  • Icons, illustrations and graphical assets should be made available in their original vector format so they can be exported to the desired file type.
  • Any images should be supplied in a high enough resolution to be resized easily. 
  • Unused components or old versions should be removed from the file, to prevent confusion.

This kind of file hygiene is important not just for handover, but also to help other designers who may join the project at a later date. After all, puzzling out incomprehensible files was never part of the job description.

Teamwork makes the dream work

Great products are the result of us all working together. By having an understanding and respect for each other’s roles, designers & developers can vastly improve the products they create. Not to mention making everyone’s work lives much easier in the process. 

Share this post

Related Posts