u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e — u p d a t e —

The first version of this article left room for inflammatory comments.

A few readers choose to continue a nonsense debate — should designers code — instead of looking at the numbers. This article is a case study not an opinionated piece.

To make it purely objective the first introductory part — Comps — and the last sections — Pain; Cure — were rewritten. The rest, the case study was untouched.

/ u p d a t e

d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r — d i s c l a i m e r —

I'm in equal measure a designer — self-taught with works featured in online galleries and theme stores — and developer — with a degree in Computer Science.

This is a privileged situation some people find it funny, others unbelievable, others take it with envy.

I use it to create with confidence, end-to-end, from user research to performance. And to share the findings with others as often as possible.

/ d i s c l a i m e r

Comps

Occasionally I do freelancing for clients and often times I'm hired at the development phase.

This means I'm receiving comps from designers either coming from Photoshop or Sketch, wrapped or not into Zeplin.

These comps are imperfect. They contain design decisions not grounded in web development best practices. Making a comp work sometimes is very painful and expensive.

I've been long waiting for a case study which speaks for itself. Let's see it.

The task

It sounds simple: list the latest posts on the homepage in a responsive way. On large screens there should be 8 posts displayed 4 in a row, on medium screens 6 posts / 3 in a row, on tablet 4 posts / 2 in a row, on mobile 2 posts each on its own row.

The comp on large screens

The comp on medium screens

The comp on tablet

The comp on mobile

The comps are blurred out to protect the designer and the company. The black and red boxes are ad placeholders, and, there are gray vertical lines between columns the blurred screenshots can't show.

The comps were replicated using mockups. You can check it live on Codepen to better sense the task.

The comp on large screens replicated with mockups

Problems

Since the designer doesn't code / doesn't consult with a developer ...

The designer doesn't know content cannot be get in a responsive way only displayed in a responsive way.

... and creates comps which makes the developer to fetch all 8 posts on the back-end and hide some of them on the front-end — such a performance waste — put to be supported by those devices which have the poorest resources.

The designer doesn't know the CSS Grid specification

... and spices up the design with vertical lines separating the columns. CSS Grid has no support for grid gap styling and a nasty hack has to be used to accomplish this original design idea.

The designer doesn't know exceptions are painful and bloat the source code

... and inserts an ad between the rows. The ad has different dimension and positioning which breaks the grid. An exception has to be added to support this design decision bloating the code during development time and later during maintenance.

Solutions

If the designer were coding or consulting with a developer the following design decisions were taken:

Do not hide posts on smaller screens — wrap them into a navigation element. This way the resources used to get all posts on the back-end would have been not wasted on the front-end. Forget the vertical column separator lines. They can't be implemented with current best practices, and they need workaround. Let form follow function even if function is coding standards. Put that ad elsewhere. Combined with 2.) it's dangerous. Moving out of the grid will spare around half of development time and budget.

With these practical design decisions the implementation would have been easy: use the CSS Grid. Time spent would be from minutes to around half an hour.

With vertical borders the CSS Grid technique — used across the site up until now — cannot be re-used. Research has to be done to see if the specification added the grid gap styling feature recently, or if there is a polyfill, or a nice workaround.

It turned out only a workaround exists which won't fully solve the problem since the suggested bordering is ... complicated: it applies to middle columns treating columns at the edge as exceptions.

Time spent with research and workarounds: around an hour.

To implement the comp a loop has to be created over grid elements adding border only where necessary. For that I've already had a component built on Flexbox. Importing, adjusting to this current project took around half an hour. If it had to be written from scratch it would take at least an hour in plus.

Inserting the ad between the posts is way more complicated. It's about adding exceptions to an existing well working code. The back-end code displaying a post list has to be modified to insert the ad; on the front-end the grid has to be re-drawn and re-bordered.

The final front-end code is so ugly it is worth a look.

Time spent: around an hour.

Numbers

The cost of the solutions Solution Duration (min) Notes Practical implementation 30 Using the CSS Grid Vertical borders — research 60 Wasted. Only a nasty hack found Vertical borders — implementation 30 +60 mins if the Flexbox grid component were not be already written Ad between rows 60 The result is a very ugly patch over a well written code

Code bloat Component Operation Exception Post list with ad Added It might be not re-used again Flexbox grid Added It might be not re-used again Responsive flexbox grid Added It might be not re-used again Responsive grid Skipped It is not re-used now while it is re-used across the entire site

Pain

This project has a good few dozens of sections like this Latest posts depicted above. More than half of them is designed in the same unimplementable way. Or, in the same costly implementable way.

Remember: on this component alone we've spent at least 2.5-3 hours instead of half an hour. Yes,

5 times or 500% more than usual.

That's immense. It all adds up during development time, and, rolls out as a technical debt for the future.

Cure

Big / well organized / informed teams might be lucky. They've probably enrolled a perfect designer ←→ developer communication strategy to avoid this kind of extra cost and technical debt.

Small teams can do three things: