Preface: I love design.
The rest of my article may make it sound like I am demonizing Designers, but NOT true. Designers are part of the ‘maker’ trifecta, with ‘Devs’ and Operations. Nothing gets done without out all three.
But getting a slick, new, UX-driven design for your website that has been market tested, and stands to increase engagement, is like buying a very expensive Christmas present….
You want it to be worth the cost!
Let’s look at that paradigm through the lens of the realistic process of ‘getting it done.’
A Designer gets asked to produce new, and unique concepts, with only 2 real pieces of information:
- Personas: The profiles of potential site visitors and users, their interests, motivations and unique details that may drive their decision making when coming to the site.
- Goals: The KPIs that the site redesign is striving to meet, usually including increases to productivity, site conversions or increased sales, all ultimately rolling up to a potential increase in revenue.
These two key data points basically give Designers the challenge of getting users to do act. Everything that goes into a design is focused on meeting data-driven goals.
From here, the designs go through review a few generations of revisions to ultimately be something that the client is excited about seeing on their site. Enter the Developers.
When these three powers combine, that’s when you get website magic. But website magic looks different to different people.
Website magic to a Marketer, looks like:
To a Developer, it looks like:
(Though, it’s usually not formatted that nicely.)
This difference in perspective is important because while a client is focused on what a website can accomplish, a Dev is more focused on how to build it.
Let’s look at a common example found on almost every site in existence, the ‘three wide card’ layout. The intention of this block is to offer a ‘call to action,’ with eye catching visuals, engaging pithy titles, and leading text to draw the user to delve deeper into the site.
In practice, these cards are a repeating block of code, inside a wrapper, styled to match designs as closely as possible. It can be broken down to the following:
On average it should take 2-4 hours to build and style this, depending on the complexity. There is a part about getting the actual values for these fields from the database, but I’m only talking about building the HTML and CSS portions.
Now, pulling an example of this from our own site, you can see that we have a very uniform application of simple, yet elegant, elements:
This is the same piece of code repeated three times inside of a containing wrapper. Which, from a development standpoint, is an example of one of the pillars of development: ‘write once, and implement as needed.’
Thus, a card layout with the same composition, whether it is displayed in a 2-wide, 3-wide, 4-wide, or cascading blocks design, should be written in code once. That single piece of code should be able to meet all the needs of a card on the site, unless there is a significantly different paradigm.
This holds true for the same layout, with a different style. In that instance, the code would remain the same, and the wrapper would get a different piece of data, allowing it to be identified as needed for the different styles. The repeated code inside would still be the same code for the existing card.
While something like that is normally not an issue at all, and a paradigm in which it is almost always possible to match designs exactly, a tiny variation can throw the whole thing into chaos.
But what if you add a small change to that. What if the client is insistent that the forward, and back buttons must be positioned in the center of the image on the card? While doable, that ask is not as easy.
“Why?” You ask, “it seems simple enough.”
Well… not so much.
It’s all about the blocks. Each card is a block, inside the wrapper block. Or to use Developer terms: the cards are the children, the wrapper is the parent, and the forward and back buttons are siblings of the wrapper. Basing the position of the buttons on the height of the image is literally like telling someone how high to stand on their toes, based on the height of a great nephew they’ve never met and is standing on the other side of a brick wall.
So what options do we have?
Well, if you know the image height will always be 150px then it’s as easy as absolutely positioning the button (inside a relatively positioned parent) and setting the top value to half the image height:
top: 75px; -ms-transform: translateY(-50%);
Done right? Eh…
When testing you may find that 150px is not always exactly 150px. If it is, then great- you’re good to go. But does that 150px render the same in Chrome, Firefox, Edge, and Safari, or are there variations between Windows, and Apple devices?
Now most Marketers worth their salt will have an idea of the most popular devices that are used by the majority of people visiting their site, and you can use that data to your benefit. By testing just in those browsers, or devices, you can quickly see whether the 75px setting works. If so great, you can stop there, but that’s never been my experience.
Now there are two ways you can accomplish an exact 50% height, but each comes with its own costs.
The first is to reconfigure the card to display so that the images are in a separate container, effectively creating two wrappers. One wrapper contains the images, and one contains the content below. This breaks the rule of ‘write it once,’ but this is a case where the layout is too different for code reuse. This also takes up more memory as you have to loop through your content twice to render the different parts within each wrapper. But both of those pale in comparison to the problems you will encounter when trying to display this configuration on mobile devices.
That said, aside from these exacting measures to achieve “pixel perfection,” you are left with solutions such as the 75px, or a lesser percentage, that are going to be close, but not always exact. It is also less problematic and more performant and from a coding perspective, much easier to implement. In fact, these small details can sometimes triple the amount of dev time. Triple the dev time is triple the cost and effectively spending 68% of the total cost on 5% of the feature.
This is only one example, and a good cause to consider how the small nuance of design can have a large impact on development cost. That’s why you need to consider either sticking to standard web paradigms, or remain flexible when it comes to devs delivering web components that vary slightly from the design.
The message here is not to hamper design creativity or to avoid pushing the boundaries. It is also not trying to tell you that perfection is out of reach. It’s that perfection comes with a cost, and the cost of perfection is usually much higher than near perfection.
The question that you have to answer is, is it worth it? Is the button displaying at 75px rather than 68 or 83 worth what could amount to hundreds of dollars in extra development time? There is no right or wrong answer- it’s about what you want to see on your website.