Responsive design

And the role of development in design

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. 🙂

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:

“…A responsive website…”

My first thought is always:

‘Well, obviously…’

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:

“What does this look like on mobile? On tablet?”

Think beyond the desktop

To quote from Ethan’s book:

Think beyond the desktop, and craft designs that respond to your users’ needs, no matter how large or small the display.

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

For context, I want to share my worst real experience of web design gone wrong. Obviously I won’t name names. I’ll just say that the website received significant traffic, including a high volume on mobile. And that the business was dependent on sales from their website. So it was a big deal to get this right!

A company had spent 3+ months and well over a $100,000 on a massive re-design of their website. They had created some beautiful 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 (or rather, it hadn’t started).

When I opened their first PSD, I discovered the website container was roughly 1,750px wide. If you’re not gasping already, 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 actually looks in a web browser, let alone on smaller screens and mobile devices.

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

“How did this happen?!”

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.

*Note: Honestly, I actually (sometimes) enjoy this challenge as a creative developer. This is more to say; Your average developer/development team will not appreciate this.

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… Brace yourself… 😬

The case for designers learning to code

I’m sticking my neck out here… But, don’t freak out! 😉 Keep on reading for my full rationale. It’s not as ‘black and white’ as you might think…

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 really understand how something works, then you’ll only ever really 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 actually works.

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

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 incredible example of dedication to your craft. I’m not suggesting we start dissecting our website’s users, or web developers! 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:

“But architects don’t know how to build!” Gotcha! 😎

Well, no. Most architects can’t build a building. But, a good architect will 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’ — often unrealistic — vision. And understandably, he wasn’t fond of some architects he worked with! (Sound familiar to the relationship between visual designers and developers?”) 🤔

But, the best architects he worked with — the ones who really knew their trade — 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 actually visually design (i.e. create detailed mockups), depends on who 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 thinking about and envisioning 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:

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’ process applies to all breakpoints. Below you can see screenshots of what it ended up looking like on mobile:


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. Now, 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!?
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:

  • ‘Designers should code.’
  • Or; ‘Developers should design.’

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 together 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.

*And I’m not talking about designers using fancy design prototyping software to create videos and simulations that imitate load states and interactions. Sorry. That’s not real. A developer still has to recreate what the designer did — as closely as they realistically can — within the budget and timeline.

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. Or, you’ll wind up with a horror story to rival mine, earlier!


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.


Thinking responsively

No designer intends 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:

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 just 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, good enough 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 not a version.
  • It’s the same website.
  • It’s the same 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.

“Someone else will figure out the other version...”

Or;

“Not as many people will see it on mobile...”

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 convenient 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.
  • Or, create a breakpoint to cover what happens when it no longer works.

I emphasise this point of thinking in percentages and not pixels because this 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.

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

  • 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 same text, spanning the same 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 — or any laptop — 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, your designer friends, and your Dribbble followers see your work like this. The end user won’t.

Hopefully, this demonstrates my point:

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, as your end users would… Or, in their hand on a mobile device.

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


I hope you and your design team find this helpful. Please share it if you did. 🙂