Responsive design

And the role of development in design

Andrew Couldwell
Dec 12, 2018 · 15 min read

This is a deep-dive into the role of development in the design process, with a focus on responsive design. It’s aimed at design leaders/managers and developers working with design teams, and visual designers looking to become better web designers. I’ll attempt to lay out the problems, and suggest practical solutions. I hope it helps. 🙂

Image for post
Image for post
Image for post
Image for post
Responsive web design. A dark art?

It’s 2018. Why are we still talking about responsive design?

I first learned responsive design back in 2011. I started out by reading Ethan Marcotte’s book, ‘Responsive Web Design’.

A dark art of web design?

Responsive design has been a thing for roughly 8-9 years now. In the early days, it was downright impressive to see a responsive website! Almost, a ‘dark art’ of web design. But, that was a long time ago.

In my role as either a designer or a developer, I find it strange that I still get asked by clients, agencies, and designers for:

My first thought is always:

But, much of my freelance web development work involves ‘making things responsive’. Designers ask me to build them a website, then send me a mockup of a desktop only website. And, my first question is always:

Think beyond the desktop

To quote from Ethan’s book:

It’s my experience that visual designers, even now, are not doing this. Or at least, not doing it well enough.

A horror story of web design gone wrong

I’ll just say that the website

A company had spent 3+ months and well over a $100,000 on a massive re-design of their website. They had created some concept work, but they were nowhere close to a build-ready design, and a hard-launch-date was growing painfully close.

The team hadn’t so much as thought about it how it would work beyond desktop. And when I quizzed the team responsible about how any of it would work at other sizes, I just got blank expressions back, like I was asking crazy questions! They genuinely didn’t see it as part of their job to think about these things.

They had designed a pretty picture of a website, only. Not anything that could be built.

Now, I’m not suggesting a period of design concept exploration isn’t worthwhile, before getting into production ready design… But, they had exhausted almost the entire project timeline, and the build was now well-behind schedule .

When I opened their first PSD, I discovered the website container was roughly 1,750px wide. consider this width would only have worked for 1-5% of traffic!

After a little digging, the reasons for all this became clear:

For months, there had been a team of visual designers lovingly crafting pixels in isolation from anyone with any responsive or development knowledge.

Tellingly, they had been reviewing their work on large TV displays, and printing mockups onto small pieces of paper, pinned on a studio wall. Amazingly, nobody during this process had considered how it looks in a web browser, let alone on smaller screens and mobile devices.

In the end, they launched on deadline. But, with only half the website built, a myriad of issues, and a lot of unhappy stakeholders angrily asking:

The developers will figure it out

This, unfortunately, is how a lot of designers think.

I’ve worked on countless projects where I’ve had to take a desktop design and turn it into a functioning, buildable, responsive website.

As a designer, I’m filling in the gaps in other designer’s work. But, as a developer, I’m going above and beyond* to finish what the designer should have.

What can we do about it?

I believe it comes down to a change in mindset:

  • To think responsively.
  • To rethink your design process.

Later in this article I’m going to cover some things I’ve tried with design teams I’ve worked with that proved successful. But first; The most contentious part of this article… 😬

The case for designers learning to code

Image for post
Image for post

😉

This mindset of ‘the developers will figure it out’ is not good enough.

However, an experienced designer is more than capable of being a good responsive web designer, if they think responsively.

It’s not as black and white as ‘designers should code’. It’s not. But, it does help.

If you don’t understand how something works, then you’ll only ever be taking a stab at it. But, developers don’t want designers taking a stab at it, then leaving it to them to figure out how it works.

We all need to do better — whether that’s designers learning to code, or working visual designers to teach them how to design better, responsive websites.

Image for post
Image for post

This is an engraving from the 16th century, called ‘Two Flayed Men and Their Skeletons’ by Italian sculptor, Domenico del Barbiere.

This work of art is representative of Italian Renaissance artists, like the great Leonardo da Vinci and Michelangelo, who dissected dead human bodies to gain a better understanding of how muscles work, so they could create more realistic paintings and sculptures.

This practice is an example of dedication to your craft. But, it’s good food for thought for how:

Gaining a better understanding of how something works is vital to doing your best work.

Dissecting a popular analogy

If you’ve ever debated ‘should designers know code’ with visual designers, you’ve probably heard this line:

Well, no. Most architects can’t build a building. But, a good architect have a good idea of what goes into it. They don’t just draw pretty pictures of buildings. They draw up schematics. They are knowledgable of the materials used — how they look, feel, respond to different light, etc.

My Dad was a Quantity Surveyor. His job involved risk assessment, and putting a price to an architects’ — — vision. And understandably, he wasn’t fond of some architects he worked with! 🤔

But, the best architects he worked with —  — designed more realistic, buildable buildings, saving everyone a lot of time and money. And, he loved working with those architects! Just like developers love working with designers who know their stuff. Which makes for a healthier work culture and a better end product.

My honest advice is:

Learn how to build what you design. It simply will make you a better web designer. I think you’ll be surprised by how much you enjoy it. It’s fun, and very satisfying to bring your own creations to life, and improve on them in the browser!

But, failing that:

All of this isn’t to say visual designers can’t be good web designers, or be taught responsive design. They just have to learn to think responsively — to think like a developer, without actually knowing code.

Two ways to approach responsive web design

There are two ways I approach web design, but, the thought process — this notion of thinking responsively — is always the same. Which, I believe is key.

Essentially, how much I visually design (i.e. create detailed mockups), depends on is building it.

Approach 1: When someone else is going to build what I design

In this case, as a designer:

  • I design every breakpoint.
  • I make sure I cover all scenarios and states.
  • I deliver responsive template designs.
  • I deliver a styleguide covering anything not obvious in the visual designs, like hover states, etc.

And the end product looks something like this:

Approach 2: When I’m going to build what I design myself

Contrary to what I’ve been saying about covering all breakpoints and scenarios — in this case — I only design for desktop. But, I’m always about and how it could look on smaller screens. Since I’m the one building it, I get into the browser as quickly as possible to validate my ideas.

An example of this approach is my personal project, Club of the Waves:

As you can see above, I only mocked up the core pages on desktop.

My design process went roughly like this:

  • This was a re-design of an existing website. So, I used Google Analytics to find out what browser size ‘most people' view the website at. Then I designed my desktop mockups to match that size.
  • From there, I designed the rest in the browser — writing code — and seeing my changes happen live. This way, I can tweak the sizes, spacing, layout and animation to my heart’s content.
  • And, I can test it at different browser sizes, adding any required breakpoints and media queries as I go.

Another example of this approach to web design is the Owl Studios website. I mocked it up on desktop, as seen below:

And then I had fun with it, in the browser:

Image for post
Image for post

I had no real plan for how the website would animate. I just felt it out, writing code, and refreshing the browser until I was happy with it. It was very much ‘a development thing’, but 100% part of the design process.

And the same ‘design in the browser’ processapplies to all breakpoints. Below you can see screenshots of what it ended up looking like on mobile:

Image for post
Image for post

The issue of fine-tuning

I’ve just described how I fine-tune a design in the browser — adding animation, tweaking sizes and spacing, etc.

Think how easy, efficient and quick that is for a creative developer to do. , imagine a designer trying to relay those same tweaks to a developer…

  • Do you supply them with round after round of tweaks by email?
  • Do you hound them on Slack?
  • Do you submit dozens of GitHub Issues?
  • Do you supply them with a new design file highlighting the changes, several times?
  • Or, do you go sit next to them, and tell them what to do!?
Image for post
Image for post
I promise you, no developer wants a designer over their shoulder, back-seat driving!

However you do it, this to-and-fro process can be very time consuming, inefficient and frustrating, for everyone. 😭

Development is design

Designers, product managers, design managers, and even developers, need to stop thinking of development as being separate from design.

And that doesn’t have to mean:

  • Or;

It means; We should work together.

HTML, CSS, and even JavaScript nowadays, are part of the design process.

Design doesn’t stop once you leave Sketch, Photoshop or XD. Or once you’ve launched a website or product.

  • We tweak our designs in the browser.
  • We test our designs with real people,
  • Then designers and developers work to iterate on the design.

Website animation is perhaps the most obvious example of how development is design. Our industry has become obsessed with animating websites. But, a designer isn’t doing that*, a developer is.

If developing things like the above isn’t considered creative, or part of the design process… Then I don’t know what is.

So, relating to the role of development in design:

Do:

Include front-end and creative developers in the design process. Get their opinions early on, and weed out any issues before it’s too late.

Don’t:

Just dump the designs on the developers at the end of the process, and hope it’s all okay.

You’re a team, act like one

A simple way to encourage designers and developers to work better together, is to have your design and development teams sit with each other. Or at least, close to each other. Don’t segregate them.

  • Dividing up your team puts up unnecessary boundaries.
  • Creates a divisive culture.
  • And makes collaboration difficult.

I’ve experienced this go wrong so many times at big companies and design agencies. It’s not healthy.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Thinking responsively

No designer to piss off developers, but sometimes they inadvertently design things that won’t work, or don’t cover all the bases. As someone who codes I understand this, but designers who purely focus on visuals often don’t. They need to learn how to think responsively — to think like a developer.

So, how do we teach visual designers to think responsively?

The answer isn’t to shout at them when they make mistakes. It’s to educate them, so they form better habits in their design process and thinking.

Below are 5 things I tried with design teams in NYC, which proved effective:

1) Design with responsive templates

Here is a Sketch template I created for a team of designers at a previous job:

Image for post
Image for post

This approach is a good way of teaching designers to think through all scenarios, and approach their designs more responsively.

A good responsive template includes:

  • An artboard to represent each breakpoint.
  • Each with the responsive grid clearly visible.
  • In this case, the breakpoints roughly equated to a ‘large’ and a ‘small’ desktop view, tablet (portrait), and mobile.

Now, I should say; I think it’s important to not think of a website as on ‘desktop’, ‘tablet’ and ‘mobile’. Or ‘breakpoint 1’, ‘breakpoint 2’ and so on… But, it is an effective way of framing it for non-technical people. And, for a visual design approach like this.

I think the important lesson here is:

Stress test

You’re unlikely to solve every responsive issue with a templated mockup approach like this, but at the very least it provides designers with a simplistic means of stress testing their designs. And with any luck, discovers any flaws in the design before they hand it to a developer.

2) It’s not a ‘version’

I think a powerful realisation for some people is to stop thinking of mobile and tablet as a ‘version’.

  • It’s a version.
  • It’s the website.
  • It’s the HTML code.
  • Only the CSS has changed.

‘Version’ is a legacy term from an era of redirecting mobile traffic to an entirely different website, targeted at mobile users — an era that superseded responsive websites. We need to move on from this legacy term.

I think this ‘version mindset’ is what holds some designers back from designing responsively.

Or;

Well, this attitude isn’t good enough anymore. Because the ‘other version’ is getting a lot more attention than some realise, or care to think. It is part of the designer’s job to think beyond desktop.

3) Design for all scenarios, not just the best case scenario

Think of a responsive layout as:

  • A UI that is near impossible to break.
  • It can take any amount of content and characters.
  • And it will work at any browser width or height.

Too often, I see designs that work only for a limited number of characters, but you can guarantee the client is going to write more words in their headline than “Lorem Ipsum.”

Don’t design with a number of characters to fit your design.

Think about the design and the content as something that work together. Not irrespective of each other.

Don’t design things to impress your designer friends, or to win an award, or to get likes on Dribbble. Ground your work in reality, and design with real content and data — or a close approximation.

4) Think in percentages, not pixels

You may design something to be 100px wide in your design software. But, in the browser, that 100px will be a percentage width of its container. So, as the browser width gets smaller, your 100px will become more like 80px, 60px, 40px, and so on.

Now, think about the content you have in that 100px area…

  • Will it work at any smaller width than 100px?
  • If not, you either need to re-think the layout, or the content.
  • , create a breakpoint to cover what happens when it no longer works.

I emphasise this point of thinking in percentages and not pixels becausethis is what visual designers at my last job struggled with the most. They just couldn’t get their head around this concept of things getting proportionally narrower, and why that’s a design problem.

Image for post
Image for post

I created this quick mockup (above) to demonstrate this point to junior (and senior) visual designers at my last job,

  • It shows the same 12 column grid, at 2 different browser widths.
  • It clearly shows how the grid columns get narrower,
  • And, what effect that has on the text, spanning the 4 columns in both scenarios.

Sometimes, seeing is believing. Demonstrating things like this, in a design mockup, or a quick demo in the browser (via a service like Codepen) can be key to getting people to understand.

5) View designs in the browser, or on a device

Going back to my horror story earlier: mistakes are easily made when we don’t ground our work in reality. So:

  • Don’t (only) review your work on large monitors or TV displays.
  • Don’t (only) print out mockups, and view them pinned on a wall.

Neither of these give an accurate depiction of what the end user will see. Which really is the only thing that matters.

Also, be careful when designing on retina screens and small laptop screens. For example, designing a website on a MacBook — is hard, because you likely can’t see the whole width of the page in the design software. So, you zoom in and out to view the work as you design. But, the problem is this: only you, see your work like this. The end user won’t.

Hopefully, this demonstrates my point:

Image for post
Image for post

On the left is your web page design mockup. Your team reviews it as a whole, cohesive design, much like you would a piece of graphic design.

But, on the right is what the user actually sees — in the browser — as they scroll. There’s a big difference! So, you must consider that reality, more so than the page as a whole.

This isn’t graphic design, it’s web design.

A good way to avoid this problem is to get to a built prototype as fast as possible. Or, the next best thing, something like an InVision prototype. This way, your team can review the work in the browser, Or, in their hand on a mobile device.

It’s important to keep perspective and ground your designs in reality.

Image for post
Image for post

Update: 2019. I wrote a book about system design and digital brand guidelines! https://designsystemfoundations.com

Owl Studios

We’re designers who code.

Thanks to Meagan Fisher

Andrew Couldwell

Written by

Web designer & developer • Portfolio at: https://roomfive.net

Owl Studios

We’re designers who code. We take on projects of all sizes, from web design and build, to product, branding and system design. http://owlstudios.co

Andrew Couldwell

Written by

Web designer & developer • Portfolio at: https://roomfive.net

Owl Studios

We’re designers who code. We take on projects of all sizes, from web design and build, to product, branding and system design. http://owlstudios.co

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store