We’ve just arrived the prototypes and technical planning sprint and up until this point the focus has been heavily swayed towards “let the creativity flow and don’t be bedevilled by what the browser can/can’t do”. Now it’s all about working out what can be done, what needs walking back and what needs fixing.

There’s two phases to this process. The first phase is where we sketch-up the creative as it sits — a concept I teach in Complete CSS — and then a round of low-fidelity, rough prototypes. Again, I teach how to use prototypes to better communicate with designers in Complete CSS.

Sketching uppermalink

I’ve been writing CSS for over 15 years and still personally rely heavily on visually planning before I build anything. You might be thinking “of course you have to plan”, but that isn’t building a backlog in Trello, Jira or Notion. It’s about grabbing a flat version of a design — in our case by exporting Figma frames — and drawing all over them.

Historically, I used to print designs and take to them with markers, mount board and scalpels, but these days, I use FigJam.

The aim of the game is to work fast and give your brain space to think about the build at an abstract level. We’re not specifically thinking about technology choices here either. Sure, you’re going to think about CSS techniques and semantic markup, naturally, but we’re not in the business of weighing up frameworks against each other.

It’s hard to grasp what we’re doing in writing, so allow me to show you with a quick video.

With that context, hopefully you get the idea of a sketch-up plan, so let’s take a look at ours for this project.

This sketch-up is different to the example above because this is a completely different context:

1. We’re in a very established project and design system
2. Visually these themes are very different but our job is to make sure they are the same under the hood
3. We have to consider both “how do we get this done” and “how do we prevent damage/debt in the codebase”

The main focus of this sketch-up is sectioning out the creative, determining if it already fits or can fit and finally, finding problems.

I can’t stress enough how important it is to find problems in planning and not in production. Sure, we’re not in a utopia, so something will always pop up in production, but avoiding breaking your flow state with blockers is really important.

I’m very much of the opinion that production coding should be pretty chilled because you’ve front-loaded your planning and have already worked out how you’re going to build the thing. The focus should be more “how can this break and how do I mitigate that?”

That’s exactly what we’re trying to do with this process. We’re giving the creative work not just fresh eyes, but completely different eyes that see things another person might not see.

Jason did all the creative for this project and Leanne did the whole sketch-up plan. Jason is really creative but doesn’t think as much in systems whereas Leanne is extremely systems-oriented. It’s all about blending those unique skillsets at this point.

The point I’m making is Leanne will see things Jason won’t (and visa-versa), so her job in this sketch-up process is to clearly identify those problems.

Catching up as a unitpermalink

Once Leanne had done her first pass as a sketch-up, we got together as a team and interrogated that work and the creative it referenced.

This part is really important because just like with a sketch-up, it’s useful to work fast. We could do the part where we all come together asynchronously — it’s how we work the vast majority of the time — but this approach allows for quick decision making and quieter notifications in Notion 😅

It gives each person an opportunity to argue their case on the details too. For example I will drive everything to be as simple as possible as a policy, but while I hack away, doing this on a team call gives Jason the opportunity to say “wait up” and add more context as to why a visual treatment is important.

By the end of the call, we’re in a position where we can break off to producing low fidelity prototypes to test potential problems areas while we tackle the immediate issues with the creative.

Some problems we foundpermalink

Let’s take a look at three problems we found during the sketch-up and the team call.

The display font for JavaScript for Everyonepermalink

This font is great but there’s a real readability problem with it. It tends to be better when it’s rendering a short phrase with clear intonation, but the font is used everywhere, including buttons.

The font was — as Jason saw it — critical to conveying the brand, which I agree with to a point, but we zoomed out and remembered what is important: readability over everything. With that reminded, Jason went back to the drawing board and worked a few alternative options. We settled on Catridge as the new display font.

Offset outline in buttons presented a wider design system riskpermalink

The Piccalilli design system isn’t the most heavily guarded system in the world, but we do really look after it. We’re mostly a bunch of design system nerds after all.

Now you might be wondering why this is a problem. It’s not a huge problem, but consider the CSS for buttons as it currently is:

.button {
  display: var(--button-display, inline-flex);
  align-items: var(--button-align-items, center);
  justify-content: var(--button-justify-content, center);
  gap: var(--button-gap, var(--space-2xs));
  padding: var(--button-padding, var(--space-xs, 0.8em) var(--space-m, 2em));
  background: var(--button-bg);
  color: var(--button-text);
  line-height: var(--button-line-height, var(--leading-slim));
  border-color: var(--button-border-color);
  border-width: var(--button-border-width, var(--stroke-weight-light));
  border-style: var(--button-border-style, solid);
  border-radius: var(--button-radius, none);
  box-shadow: var(--button-box-shadow, none);
  text-decoration: none;
  text-transform: var(--button-text-transform, uppercase);
  font-weight: var(--button-font-weight, var(--font-bold));
  font-size: var(--button-font-size, var(--size-step--3));
  font-family: var(--button-font-family, var(--font-display));
  letter-spacing: var(--button-kerning, var(--kerning));
  cursor: pointer;
}

This is just the main .button class, but it also inherits this base focus style:

:focus-visible {
	outline-color: var(--focus-ring-color);
	outline-style: var(--focus-ring-style);
	outline-offset: var(--focus-ring-offset);
	outline-width: var(--focus-ring-width);
}

The second part rules out using outline which would give us that offset. Modern browsers support border radius with outline too. It’s just a bit hacky to do that and we want to maintain the global focus treatment across the site without overriding, the overriding again.

We could achieve this treatment by adding a child element to the button but that sort of treatment in an existing design system is a big decision to make with potentially wide-reaching consequences, so we have to ask ourselves, “is this treatment worth all of that work?“. Of course not, so an alternative is needed to simplify.

Visual treatment also presented a wider design system riskpermalink

One nice detail introduced in the creative exploration was a little folded corner in the header for Mindful Design. It was a wink and a nod to how Scott runs his design workshops: lots of post-it notes.

Similarly to the button, we have to ask ourselves if we want to add additional CSS and markup everywhere to accommodate this one bit of treatment.

As we saw it during this process, it’s very subtle but potentially problematic on small viewports because there’s a risk of the smaller gutter not giving enough space for the corner to visually collide. We’re also using that treatment further down the page too, so again, a re-think is needed.

Now it’s over to Jason to talk about how he resolved these problems prior to prototypes being produced.