Why designers should understand code
A counter argument to ‘designers don’t need to know how to code’, from the perspective of a developer.
As designers it’s easy to get annoyed with developers. Perhaps they can’t get the alignment of a button right; or that feature you deemed critical to your UX is just too far down the backlog for your comfort.
The reality is that we get annoyed with developers mostly because we don’t understand their world. The same goes for developers’ lack of understanding of design — they get pretty annoyed with us too.
I know this because I’ve filled both shoes, having spent most of my life designing and developing for web.
We’re all guilty of it on some level. As designers we put our blue sky hats on and design to our heart’s content without considering the technical implications.
This doesn’t necessarily mean we should restrict ourselves; but it does emphasize the importance of sticking to a project scope and ensuring alignment across your team.
With that said, there might be cases where the scope supplied to you just isn’t detailed enough. You start inventing functionality or components and often you might sell this to business without any technical consultation. This is dangerous and could easily result in scope creep and a final product that’s delayed or over budget.
Another likely scenario is when you’re a one man show, designing in isolation. You expect the flat designs you hand over to be pixel perfect but this is hardly ever the case. Your developer does not care about user experience — and this is completely fair because it’s not their job.
Unfortunately many companies are not mature enough in their design approach to avoid these scenarios. Engineering conversations are too often filled with jargon that designers don’t understand, resulting in mixed deliverables. Design is also at times brought into the process when the engineering work is already done and when it’s nearly impossible to make any design changes.
Bridging this gap might require us, as designers, to know a little bit more about development.
This is not to say that designers need to be full stack engineers, but I’m a firm believer in having a basic understanding of some technical concepts. It will reduce friction, help your team produce better products, and ultimately make you much better at your job.
Data and data structures
Data is the cornerstone of any application. Most applications might use what is called CRUD operations: Create, Read, Update and Delete. These operations are used to manage data, but the kicker is that functions or API calls need to be written for each of these operations, and often for each data set.
In a designer’s mind, adding an avatar picture to a profile section seems like a no-brainer. In reality though, a developer needs to write a full set of CRUD operations for this piece of design. Further to this they need to write code to link this avatar up to your profile, and provide a fallback image, and manage where the files are stored on a server. That small design change might have taken you five minutes, but could easily add a day or two to a sprint.
There is also a second part to this: Where the actual data for this profile image is stored. Generally developers would design databases that are easy to scale, but sometimes we might force structure changes by designing new features.
I’m very guilty of this one myself. I designed a web app that allowed you to find location based specials. After some feedback from users I realized that we were missing a very key feature: Customizing the same promotion for different stores. As a designer this problem was very simple to solve: I just had to add some buttons to the back-end and split out one of the admin processes. For the developers however it was a nightmare.
The reality was that the database had to be redesigned and the admin processes rebuilt — I couldn’t afford this and my project fell out of budget and failed. This was not because the developers didn’t know what they were doing, but because I had changed the scope.
It’s important that we are cognizant of the constraints when it comes to the design of an application’s database, as well as the code required to read and write that data. Think about how pieces of data relate to one another; and remember that each piece of text you add to your design needs to live in a database table somewhere.
Asset generation and performance
Most developers take the performance of their applications quite seriously — I’m obsessed myself and count every millisecond I shave off as a champagne worthy victory.
Performance is key to a good user experience, which means that the performance of your product is as much your job as it is a developer’s. It is our responsibility as designers to hand over assets and prototypes that consider the application’s performance and this is only possible with a solid understanding of the technology you are designing for.
Imagery is one type of asset that a lot of designers don’t hand over properly. It might be tempting to crank up that quality slider to 12 when saving out a JPG but at the end of the day your users will suffer for it. Most WordPress themes for example don’t resize images when you upload or use them in production. Yes you can solve this with a plug-in or two, but why not just save it out correctly from the start?
There are some very useful tools for testing image sizes (and services like Google Page Speed Insights even offer compression). Run your live site through these tools and supply your developers with the appropriate compressed images.
Another consideration is SEO. Something simple, such as naming your file in a semantic way, can have a huge impact on your project’s search rank. It might seem ridiculous to call that thumbnail ‘a-photo-of-an-apple-on-a-cutting-board.jpg’ but Google actually reads this metadata.
Lastly this is not only applicable to imagery, but also video. Suggest a third-party service like YouTube or Vimeo — your developers will love you for it as it does all the heavy lifting for them.
No, I can’t improve the performance of your full page transition on IE6.
Another thing we’re guilty of is overdoing animation. Sure, that transition might seem smooth and sexy on your iMac Pro but what about the rest of your audience that might be using old laptops? The same thinking goes for other devices like feature phones or older tablets.
Animation can add a lot of bloat to code as developers might need to implement additional libraries to execute it. Additionally it might add unnecessary scope — advanced shape animation for example would require HTML canvas which is often a specialist skill.
It’s important that animation is considered and meaningful. This will ensure that developers are implementing only animation that is relevant to your end-user’s experience.
You can read more about creating meaningful animation here, or read more about analyzing performance here.
Technical execution
When wearing my dev hat I sometimes receive designs that are hard to implement; and this is often because the designer does not fully understand what’s involved in the implementation. CSS and JavaScript for example has its limitations — there’s just some native mobile features that can’t be used for web. Then we also need to consider things like browser support, as well as the effort involved to make a design cross-browser compatible.
With that said, most designs are executable, it’s just about finding a compromise between scope and what’s best for the user. Having a solid understanding of CSS and the web will help this process along and will reduce friction between you and your developers.
Ensure that your process is agile in nature — check in with a developer on a regular basis to confirm that your design is executable and within scope. Designing quick prototypes is a great way to showcase your thinking and often your developers might use this to build prototypes of their own. This is great for collaboration and will avoid those design pitfalls.
Lastly, never show final designs to a client without ensuring that they are executable and within your project’s scope.
CSS and JavaScript frameworks or libraries
Bootstrap was a turning point for many web professionals. It allowed developers to build websites without designers, and allowed designers to design in a language that developers could understand. In a way Bootstrap was one of the first design systems for the web and allowed for better collaboration between teams.
Bootstrap uses a concept called CSS preprocessing. This allows developers to separate UI styles for different components into their own files. It also allows them to abstract certain properties out as variables, especially if they are repeatedly used in multiple components.
React, Vue and Angular (all JavaScript frameworks/libraries) follow very similar methodologies. These data driven, Single Page Application tools have enabled developers to build highly scale-able web applications that are very modular in nature. Components are separated into their own functional files and often contain the styling (CSS) as well.
Understanding this concept of separation of concerns allow designers to abstract their design work into design tokens, which creates a shared language that both designers and developers can understand.
This shared language is a powerful tool that eliminates jargon from the conversation. It empowers designers to be part of project scoping and sprint planning. There would be no doubt between you and your developer when you ask them to change a button from ‘small’ to ‘large’, as the component and it’s relevant styling is abstracted out. This ultimately could lead to a design system, which allows design to roll out at scale.
To conclude
I’m not saying that designers need to be hard-core developers, but a little understanding goes a long way. Learn from developers and help them learn from you, so that we can all build better products.
