Design Doesn’t Stop When the Code Starts

Startup Stock Photos

In the context of software engineering, web design and mobile design there are many approaches to marry the work of designers with developers. Many times the right approach is the one that helps you set your team’s rhythm, working harmoniously and delivering to your clients. Even so, it’s worth having a peek at other approaches and stealing some of their values and processes to improve your own. In this post we’ll discuss one approach, what design means to me and hopefully you’ll be able to take something away from it.

Keep your designs closeby

You may have taken a subconscious hint with the featured image in this post; the person has their notebook out and their Macbook out, a behaviour I want my teammates to make a habit. Even if the layout and design of the website or experience you’re developing is all laid out for you, it is important to keep referring to those design decisions regularly as you go. There’s more than one reason for doing so.

Firstly is to ensure you keep on track. Bit boring and explicit, but if the design was done correctly then a lot of questions you would normally have should be answered and manifest in the design itself. This should be annotated in the design notes too to assist you whilst building, but keep in mind that it’s not always correct. Secondly is to rework any difficulties you encounter, either because something couldn’t be implemented the way you envisaged or an issue or improvement may create a domino effect requiring modifications to several other parts.

Designs will ultimately be implemented somewhere

Part of my motivation to learn to truly develop software comes from my refusal to create weird and wonderful designs that will never see the light of day. In addition, it makes the development team’s job a nightmare. In this vein, the design and development minds need to keep in close communication as both the design is emerging and the development comes to life to help keep the vision in mind whilst creating what’s possible. It’s not good enough to design something and then pawn it off to the development team to clean up your optimistic mess. Take some responsibility and collaborate together!

Tweak the design as the product takes shape

As I alluded to in the previous two sections, the design need not be set in stone before development begins and this presents two advantages. Firstly is that things don’t need to be perfect the first time as you have the opportunity to mould your work. Secondly if you’re a designer and don’t have much development experience, you can collaborate with the development team to see what’s possible and incorporate what you’ve learned from them in any future work. Not only will this help pivot development early as soon as problems are discovered, but will often lead to a reduced time to market.

Some designs require a different toolset

This is where a typical developer would actually be making a design choice – some projects and pieces of work require a different toolset to the one that they’d normally use. The tools that you use to build a proof-of-concept will differ wildly to a bank-grade application expected to grow to millions of users in a couple of years. Likewise, keeping in mind the expected timeline can inform the design to how “pixel perfect” it needs to be. By collaborating together and remembering the business objectives, you will end up selecting the appropriate design language as well as the appropriate development tools that can complement each other.


From all the above themes you may have noticed there isn’t a defined entry point and exit point to designing, when married with the development process. Design can be trickled down into every facet of everyday development. Those of you who know my background will know that this is also part of the DevOps mindset – testing and deploying code should be easy and automatic just like designing should complement the development process.

TLDR; designers and developers must collaborate together, keep the designs to hand as you develop, each side should help inform the other as the product evolves and finally meet the business objectives with adequate and complementary tools – don’t use a sledgehammer to open up a walnut.

Until next time,

– Chuck

Image credit:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s