Role(s): Design: w/ Creative Director Ahmed Khalil
Front-end development: html, css, javascript, static site built on Jekyll

Highlights: Content first, typography forward
Minimal navigation pattern
Collaborative, iterative, in-browser design/build
Robust responsive design system

Background: I worked at Yellow Pencil (YP) for nearly 8 years, from September 2015 to April 2023. When I started, YP was a completely flat organization, and my role was simply "Designer", like all the other designers.

Over time the organization grew, and I grew with it. I took on product manager, product designer, and eventually Associate Director of Design roles. One of the things I did in this role was to pick up design tasks that weren't related directly to client work. One of those tasks was to remake our company's own website.

Approach: We'd been struggling to find the time and resources to get our site updated, and it occurred to me that we might be taking the wrong approach. At the time, then Creative Director Ahmed Khalil had been working on designs for the new site, which were beautiful and elegant, but we were having a hard time getting the project to move forward. We'd been following a "waterfall" kind of process, where Ahmed had to finish all the designs which were then to be implemented by a contractor.

The process meant Ahmed had to design every page and pattern at every size to give the developer enough information to build the site well. A gargantuan task to complete on top of a busy schedule.

The developer would then be overwhelmed with design details, making it difficult to build the site at the same fidelity as the mockups.

The process involved a kind of rework. First Ahmed had to define a design system and implement it graphically. Then the developer had to re-interpret that design system as code and implement it again – accurately.

The distance between design and the front-end development work was making the whole process more difficult. They needed to be closer together if we wanted to get quick results.

So I proposed that Ahmed and I work on a new design together, take a simpler approach, and design it in the browser as much as possible. The idea was that if we could design it in-browser, by the time the design was done, the development would also be done. This meant we'd be able to deliver a product much more quickly.

This approach turned out to be a success. We started by launching a "Minimum Viable Product" of the site and then iterated on it from there.

Content first: Yellow Pencil's work is based on a strong content design practice. The content for the new site was developed before the design work began, then further refined throughout the process. The content was also the primary focus in our approach to the visual design of the site. We did this by basing our design approach on typography. Typography is very useful for the clear presentation of content.

It's also useful for achieving other design goals such as usability and accessibility. Good typography brings an aesthetic value to text that is often lacking on the web. And much of the web is text. We wanted our site to look great without relying on flashy banner images. We did away with any unnecessary UI elements. We went type-centric, instead of UI-centric.

---

Minimal navigation: It's rare to have license to experiment with navigation patterns. Both client- and service-side teams have a strong expectation for the conventional approach. I have an opinion about the ubiquitous global navigation UI pattern seen on every site ever :

it doesn't need to be at the top of every page. We easily package it all up under a "hamburger" icon on mobile devices, and no one seems to mind. And when we're on desktop we have even more places to put it. I like to put navigation at the bottom of the page. My assumption being that people may want to read the page they're on before going somewhere else. They may even need to read it before knowing where to go next. Main navigation can comfortably sit in the footer on desktop sites. You can put a "menu" anchor link in the header to send users there when they need it.

I know, I know, it's backwards, at least from the conventional perspective. Here are some counter points:

• Books have a table of contents in the front of the book, not on every page. It doesn't really have to be on every page if there's an easy way to get to it.
• Complex headers consume a large amount of energy and resources. They are costly. First, designing and implementing them takes a lot of effort. They are over-crowded with functionality, branding, drop downs, megamenus, log ins and alerts. So that's one kind of cost: design / development.
• But it costs you something even more dear than design and development time: attention. The more things you put in your readers' eyes, the less they'll see any one of them.
• Complex header navigation systems can also be fragile. Often adding one more navigation element causes the whole layout to break.

Good design requires managing complexity : visual complexity and interactive complexity. No one can actually navigate your complex header and read the page at the same time. There's no reason to show them both at once. Make it modal. Do one or the other. Go into nav mode. Put the nav somewhere else, like maybe a full sitemap on the homepage (kinda like craigslist?). There are so many ways you could go that don't involve putting a hundred elements in the top inch of the screen. It is nice to have easy access to navigation from that top bar, but we don't need to show it all at once.

---

See? That's how I get about this stuff. I rant. I wax philosophical. I care.

But I had a point I was getting to: because it was our own site we had license to make decisions. So we were able to innovate in our approach to the navigation.

We did three things here. First, we kept our main navigation items very limited. Just four. This allowed us to keep those four elements in a more-or-less conventional location at the top right of the page where they're easy to find. We did not extend this system with any kind of sub-navigation, flyouts, etc. We kept it simple: Work, Solutions, Team, and Careers.

To navigate deeper into the website, a user landing on the home page would first have to enter one of those four areas. Content on the home page also directs users to each section of the site, introducing each in turn. Each of these four areas has its own landing page. These pages contain relevant content and a menu of links that take the reader deeper into the site.

For example, from the Work page, the reader can choose from a menu of case studies about past work. This same menu is then displayed again at the bottom of each of the case studies. This approach merges content and navigation into a single system. It encourages people to engage with the content, and it puts navigation in a place where it makes sense.

We also implemented our very own OnPoint Search, which further addresses the perceived need for a big nav bar. If people are looking for something specific, they can search for it. If not, the site will lead them to it.

---

Responsive design: The Yellow Pencil site design works from the smallest device sizes up to the largest desktop monitors, that's a range of 320px to 2560px, and beyond.

Responsive design is a technology that allows us to optimize design systems for different viewport formats. It was popularized around 2012, when the biggest screens on the market were 1280px wide.

Today, over ten years later, the landscape of devices has changed, but our approaches to responsive design have not. The most common viewport in use today is 1920px wide. Most "responsive" sites still don't respond above 1280px.

The screen I'm looking at right now as I write this is 2560px. That's exactly double the width most "responsive" sites cap out at. Double!

As a designer, I can't imagine ignoring half the space in any other medium.

I think this situation is no good. I'm on a personal mission to find ways to think about, design and build more responsive systems. And I feel I made significant progress on this mission with Yellow Pencil's site.

---

Responsive hero images: Another place we were able to innovate in the design of the Yellow Pencil website was with the hero images. One of the puzzles of responsive design is that text and images scale differently. Text flows, and can be "reflowed" into different shaped containers – narrow or wide – and still function reasonably well. Images are more restrained. Generally speaking, you can't change the shape of an image. If you pinch or stretch them they look weird, and cropping them can result in loss of important parts of the image.

The approach we took was to build a kind of "reflowable" system for the hero images. The main illustration conforms to a template with a "safe zone". This safe zone lets us crop the image in the front-end with confidence, because we know exactly where the important subject matter in the image will be. Imagery within the safe zone is always shown. When there's enough room , we show more of the illustration. Shapes and layers can be added or removed to balance the composition of the image with the layout of the page.