Your website is broke and you don’t know how to fix it – what do you do?

design-systems

Today I ran into an obscure JavaScript error that seemed to only be present on the CMS build. I ran through the usual suspects: trying a few tricks I know, scouring Google and Stack Overflow for a similar answer, and hitting up the GitHub issues on the related projects.

They were all of no use in this case. Many issues seemed similar, but none of the solutions seemed to work.

And an error in JavaScript on the browser is difficult. This is because stops the processing of JavaScript and thus breaks the functionality of your site.

Luckily for this project I had a solid set of front-end code built out. Since the CMS implementation used a common set of build tools and templates, I could quickly find the answer.

But first let me tell you how I learned this technique. Back in my 20’s I used to work as a contractor for Apple telephone tech support in Sacramento.

The single most important takeaway from this job is the idea of isolation.

In their case they applied it to troubleshooting computer hardware, but it can be used for literally anything. I have used it myself in countless other applications, including troubleshooting and fixing automobiles.

The idea is that you want to isolate the issue you are having. On a computer you can do that by removing everything and only connecting the bare minimum. On a website, it is no so easy to disconnect things.

That is where quality front-end code comes in. This allows you to have something that is simple and can be easily isolated.

It gives you a test bed that is decoupled from your working site where you can test ideas and solve any issues that arise. It can then act as a blueprint as you roll the changes back out to your production product.

This gives you efficiency, the ability to use a variety of tools in your troubleshooting process, and to speed up your progress by limiting the number of moving parts.

I wondered what I might have done if I didn’t have the front-end code available.

I suppose I could have continued searching, but I am not sure I would find a solution. I guess I could asked around to see if anyone had the same issue. Or I could tried to fix it by trial and error.

The common thread here is that all of these would have been terribly inefficient and burned a lot of time. Design Systems Engineering if done right, gives you a set of tools to get some of that time back. And, with a lot less uncertainty and stress.

This is what the process looked like instead.

I used a tool called Kdiff 3 which has a nice feature of being able to compare entire directory structures of files against each other. It annotates files that have differences with a red color, which allows you to see which files are different between the two sets. It allows you to also see in each file, what is different and what is the same.

I used this tool to compare my front-end code against my CMS build. I able to identify the offending line of code and quickly patch it. Simple, clean, and easy.

Why do I think about design systems while waiting for food?

design-systems

Today while waiting in a line for a buffet, I had a thought. I wondered why they always serve a buffet when there are many people to feed.

Here I was in line with a bunch of professors and hungry grad (and potential grad) students. Everyone was getting hungry and impatient fast.

So I thought back to other similar experiences.

I have been doing a fair amount of traveling lately. Some of the hotels I stay at offer a complementary breakfast. And one popular option is to build a custom omelette.

The process goes something like this…

Would you like an omelette?

Sure.

What would you like on it?

What are the options?

Well… (and they read off a list of possible ingredients in an arbitrary order.) (and you have to wait until they finish.) (not to mention memorize the ingredients you want.)

Then you order.

They take the order back to the kitchen on a piece of paper.

The chef prepares the omelette and it brought to your table._

This works great for one or two guests. But what about when you have 100?

That is when this inefficient process breaks down.

This is similar to custom web development. By not having a proper set of guidelines and processes to drive your project workflow can really slow things down.

Let’s flashback to today, the buffet line example.

Here almost all the decisions have been made for you in advance. All you need to do when you get to the front is pick up a plate and go to the first item.

You only have to ask yourself one question. Do I want this item, yes or no?

There is nothing to memorize. You don’t have to wait for something to be prepared. No crazy list of options to memorize.

While standing in line I realized that this is the superior choice.

All I had to decide was what components, er… food, I wanted on my plate.

This is all because someone smart, the chef, spent some time to think about what patterns I would like to consume. Homemade pita chips. A samosa. Chicken Satay. It wasn’t arbitrary–it was a curated experience.

Build a design buffet for your engineers by creating a system of modular components. With this they can work faster, in parallel, plunking down the right components just as they need them. They should have to make ideally zero decisions. Just do they want the component, yes or no.

The next time you find yourself in a queue for food, put yourself in your developer’s shoes (have some empathy), and dream up that perfect design buffet.