Part 2: An analytical perspective on design, performance and content

As a website owner or content producer, a style guide can be the natural place to document the communicative style you intend to use in digital contexts. The style guide also contains other things, such as the organisation's web guidelines, design patterns, performance budget and much more. Where the graphic profile ends in digital contexts, the style guide takes over. Such as setting requirements for interaction, something called a performance budget.

A performance budget is the place where you set your minimum level, that is, what standard you at the very least want to maintain on your website. This level can cover anything you want to define for how the website should perform. A few overdrafts of this budget are nothing to get worked up about, but at the same time projects should not be carried out in violation of the budget you have set up.

I realise I may need to explain how design is connected to analysis, and follow-up in general. The reason this part is worth considering is that if you do not have a consistent or deliberate design and requirements specification, it becomes harder to rule out design factors as noise in your collected data. For example, you might ask yourself how meaningful it is to test a new colour on call-to-action buttons if you are already very inconsistent.

If you neither follow design conventions users have learned nor are consistent in your own design, you are not making the most of the user experience. It also becomes difficult to follow up how the website performs. That is the reason why a web analyst should take at least a little interest in design questions in broad strokes and sometimes be a bit questioning about graphic details within visual design.

My own employer's website had until 2016 masses of different ways to style links. I do not know how many there were in the original layout but there were more and more over time. This was probably because there was no governance of design decisions. The governance that did exist stipulated that you were not allowed to place links in the body text. Sometimes a link was underlined, while the link in the column next to it was not. It also happened that links in lists had a colourful icon next to them, but sometimes they consisted of ordinary bullet lists. Some links were black, others were blue, unless they were white. What happened when you moved a mouse cursor over a link also varied; sometimes the links that lacked an underline were given one, but that was not something you could count on. In addition to the images that were clickable, links could have three different colours, be bold or regular text, sometimes headings, or be underlined. Linked images were also a mix of everything, partly the then common flat design, but sometimes some form of image with a shadow effect behind it – so-called skeuomorphic design, that which imitates how a physical counterpart might look.

: Image 21: A selection of links from the start page of vgregion.se, many different appearances, not always obvious what is a link (2015).

At the next redesign, during 2015, we took the opportunity to try to start governing the design, and Region Västra Götaland's style guide was born. Released as usual with a free licence so others can make a copy and adapt it to their own needs.

What we often find in a style guide is language guidelines, such as tips on sentence length, how things should look, so-called design patterns, and general tips. We shall shortly go through each part.

: Image 22: First version of Region Västra Götaland's style guide.

A more extreme example specifically regarding colour choices I heard from Expressen's lead frontend developer. They had just on the start page of expressen.se a full 24 different shades of their red colour. This was not due to any requirement from those who commission design for the website, but rather because the developers themselves chose a red colour when they needed to make something red. Perhaps it was that insight that led Expressen to develop a style guide and standardise which colours are the correct ones. With a style guide they took control over how users would understand and interpret their website.

Style guides are in themselves nothing new. However, it is one of the few things the web did not inherit from print producers already during the 1990s. A style guide can be an umbrella term and gathering place for all documentation about how you conduct your communication in digital contexts. Within established businesses, you have surely already got some parts of what can constitute a style guide. Possibly they are called guidelines, handbooks, design manuals or similar. Sometimes these only apply to the physical reality such as signs or print materials and sometimes they apply to more digital things. A very relevant and extremely communicative example of content to consider for your style guide is the New York Times' document of “forbidden” words. That is, their linguistic style.

: Image 23: The New York Times' list of words to avoid.

The reason you should gather all documentation in a common place is because if people do not have to search in multiple places, compliance with this documented wisdom is likely to increase. That is why I think it is smart to be inclusive in what you choose to include in your style guide; even what is not very digital can probably be useful.

It is a bit strange that style guides did not become a given at the same time as responsive web design broke through. Since you in the design phase for a responsive website are forced to start talking about how a design element should look on different sized screens, the need for a documented design should be almost obvious. How else would you know how a design pattern, like the main menu, behaves and looks on different screens? Initially, at some organisations, these were recorded in something called pattern libraries. That is, the organisation's library of design patterns. Now, design patterns seem to increasingly be part of the publicly available style guides we can find on the web.

: Image 24: Design pattern for a search box.

During the first decade of the 2000s, many organisations have probably been treading water a bit in their web work. Many are perhaps halfway into maturing in their web work, but still lack certain parts that exist in the “regular” communication and marketing work. Few seem to have come particularly far with an equally complete digital part of their graphic manual, at least compared to what applies to print materials.

Redesigning? Create a design budget!

If you have the fortune of being able to coordinate the work of creating a new website, or at least redesigning it, and tackling the work with a style guide's design patterns, you should count your lucky stars. One way to have concrete and comprehensible constraints in your design work is to work with something that can be called a design budget. It is a way to avoid the often occurring discussions about it being difficult to prioritise since apparently everything is always the most important.

Emerging best practice in web design is to begin the design work by setting up a design budget. A design budget involves designing pages and templates in a restrained way. To make this restraint concrete, you have a point system that controls how many design components end up on, for example, a landing page. Say you start by setting a cap of twenty points as the budget for each individual page view. Are you going to include a large block with an image and a call-to-action button? Then you will have used up six points just on that large image. Are you then going to have an image carousel? Then perhaps another ten points disappear due to more heavy images but also an extra JavaScript dependency for the actual image browsing.

An advantage of making a design budget is that it is hard to fix this type of problem afterwards when all decisions have been taken. And that you are probably more willing to compromise at the beginning of a project.

Barbara Bermes has the following suggested point system in her excellent book Lean Websites²⁰.

Design pattern	Points	Description
Low impact	1	Small images, static content, simple graphics, buttons and text fields.
Medium impact	2	Medium-sized images and simple scripts.
High impact	6	Large images, third-party services, third-party advertisements.

The biggest benefit of a design budget is to make concrete each design decision's impact on the website; it becomes concrete for those who have no reason to talk about this in more technical terms (that is where the performance budget comes in, something we will get to shortly).

If you want to play devil's advocate on design decisions, you can constantly propose A/B testing the users' acceptance of each idea. Perhaps pages with higher scores work. Perhaps your cap can be twenty-five points rather than twenty for a landing page and it performs at the same level? But by all means also test the assumption that fewer design points yield more benefit, and where the limit lies.

As Karen McGrane points out in her book Going Responsive²¹, in the chapter Clean up your content, it is in the design or evaluation phase that you have a golden opportunity to sit down together and make the difficult prioritisations about what content should exist, and what is actually most important. It is now you also think mobile first, small screens, slow connection, etc. Answers to these questions are not received via email – you need to meet. During such a meeting, you must be able to make decisions. It is also now that it is possible to address the inability that often exists to single out one thing as most important per page. If only one thing fits on a screen, what should that be? There are no shared first places in mobile first.

We've remade the Internet in our own image, which, in the United States, is obese.
- Jason Grigsby²²

You have probably figured out that with this approach you need to be frugal with resources in the header and footer. Otherwise there will be very little left for the unique content on each web page to use.

If you cannot be bothered with the point system for design decisions, you can instead have a battery of questions that sort out how design affects the experience's speed, whether it adds to the cognitive burden for the user. For example, questions about how the design proposal affects the brand, or encroaches on existing design patterns, are complemented with questions such as:

Will it affect the number of files that need to be downloaded?
Will the page view become heavier?
How will perceived performance be affected?
Will the user become mentally overloaded or have difficulty interpreting the options available?

The point is to concretise design in more dimensions than the strictly aesthetic to a greater extent. We are already accustomed to asking business questions such as what it might cost, how long it takes to complete and what value it is thought to have for the business. Many organisations are considerably worse at asking design questions, such as why colour is used in a certain way, or the necessity of decoration.

An addition to this is what Lara Hogan addresses in her book Designing for Performance²³. She shows that you make your design budget specific per breakpoint on the website. For those of you not well-versed in web design, it may be worth knowing that a breakpoint is the magic widths on the website when the design changes to make the most of available space. It is part of the concept of responsive web design. A small screen has less ability to show a lot at once and therefore it becomes perhaps even more important not to be wasteful.

Design is also a golden opportunity to plan for your continuous web analytics. For example, several hypotheses about how much impact the number of design elements has on mobile users can be evaluated methodically with A/B tests once the design is finished and published. Then you can start testing what works on actual users, unless you work with early design prototypes before it has been built.

Evaluating how a design performs can be very technical. You will notice that shortly when we address the concept of performance budget. The design budget is the opportunity you have to talk performance, and results, in relation to how something will roughly look.

As a web analyst you can contribute in many ways to the discussion about a design budget. Not least by planning for a comparison between pages that have drastically different numbers of design elements, or what contrasts you find curiosity in investigating. An interesting anecdote I heard from Expressen's lead frontend developer was that they had A/B-tested how well their visitors converted, and curiously enough the conversion rate was higher on the cluttered pages. When they then made the not-quite-as-cluttered pages a bit “worse”, those pages also got a higher conversion rate.

It is important to challenge your assumptions, evidently!

Content budget

Those of you who have read my book Webbstrategi för alla²⁴ or follow my blog have probably noticed how often I refer to all the good things the English Gov.uk does. They are admittedly not alone in having checklists for how to think about your content on the web, but they are good at speaking openly about why they do things the way they do.

Most organisations I have encountered do have handbooks for how to write, but very few have, like Gov.uk, gone far in adapting this wisdom to the web. Here is how they for example describe how a page title should be formulated²⁵:

clear and specific
optimised for search
under 65 characters (including spaces)
unique within the site (check search results on GOV.UK)
in sentence case
written in plain English (no jargon)

Even more interesting are perhaps the guidelines for body text:

begin with what's most important to users (not to government)
be concise and easy to scan (with sub-heads every 3-5 paragraphs)
be written in plain English (no jargon) and easy to understand
use short sentences (around 25 words)
define acronyms and abbreviations the first time they're used (with Markdown)
explain any technical terms
be shorter than 500 words, if possible

As you can see in these examples, certain limitations are placed on how you work with content and its various quantities. Not entirely unlike a budget. Your content budget will surely be challenged and questioned. Gov.uk's decision to keep body text under 500 words is probably in the firing line immediately if they bring in a consultant for some search engine optimisation. SEO best practice at the time this book is written is that a text should be at least three hundred words – but preferably around a thousand. I think the point of having a content budget is the discussion itself about how you view your content. You document your intention so that all ideas come to the surface and that when needed it is possible to discuss and revise them.

Now there are always competing perspectives, and different professional groups gladly bring their own facts, best practice or evidence into a discussion. The content budget is the organisation's own documented best practice in content matters; they should not be changed arbitrarily. One way is of course to change your mind based on your own tests, but until then, research and external best practice is the best you have to go by.

The reason Gov.uk chose that sentences should not exceed twenty-five words²⁶ is based on research. Research shows that when the average sentence length is fourteen words, at least 90% of readers understand what they read. At forty-three words per sentence, it drops below 10%. Studies also show that at twenty-one words per sentence, a text starts to be somewhat complex to absorb. Choosing twenty-five words per sentence as the limit should be considered quite generous, I think, but I also suspect that most have no ambition at all in this area.

If you work according to the mantra content first²⁷, then a content budget is the equivalent of what a design budget is for those who start with the design. Those of you wondering how on earth you follow up that this is adhered to will have to be patient; later in the book you will find tips on how you work with content analysis, or index analysis as search people often call it.

Style guide = communicative style, pattern library and performance budget

We have already in this part of the book gone through some of the documented ambition level one can have with one's web presence, but there are of course more things to put in writing (digitally).

An organisation's style guide should, I think, be a collective name for all the documentation that concerns the organisation's communicative style – in a broad sense. Lots of different parts can be included, with few common denominators. Often there are already tips and guidelines about the linguistic, not infrequently something about typography in digital contexts, sometimes design sketches that specify exactly how the logotype and other design elements should be handled to protect the organisation's identity.

More recently, it has become increasingly common to also document a more technical handbook containing code examples for web development, key performance indicators for follow-up of the website, and a performance budget for the prioritised quality criteria that have been selected.

Many communicative parts should probably be addressed. Perhaps not word choices in themselves but rather how you find out what language use is expected and that the words you have actually chosen have the conditions to reach their target. For example, that there is limited space for how many words are shown at Google, in the user's browser, etc. The style guide can actually come with both stick and carrot. The stick consisting of the guidelines that say what you are allowed to do, and the carrot being the tips on how to succeed under the prevailing conditions on the web.

Pattern library

: Image 25: Example of a style guide. Introduction with tips on how it is used, then a pattern library for reuse.

Instead of designing entire pages, you are usually recommended to design your design patterns first; the concept for this is Atomic Design²⁸. You may have encountered this concept under other names; the most common synonym in Sweden is probably component-based design. It is a bit like which building blocks you need in your stockroom to be able to build something. These are increasingly called design patterns (in Swedish “designmönster”), and the collection of design patterns is called a pattern library.

Examples of design patterns can be what the search function looks like, that is, the search field, the button and things around it. Or what an image looks like together with its caption. This is useful, just like specialised Lego bricks, when you want to reuse something in a different context at a later point. Then part of the work is already done. You do not need to wonder how many pixels radius the search field's rounded corners should have; you just copy what has already been produced.

If you do not also decide exactly which interface code should be used alongside your design pattern, you have only done half the job. It is not necessarily the case that code should be the focus, but if no code is given, it becomes difficult as all developers must themselves invent their own code to make something look and function as desired. You can safely count on not everyone being equally motivated to choose the right colour, or ensure that it scales well on different sized screens, or even that it is accessible enough to comply with anti-discrimination legislation. It is thus recommended that code accompanies the design pattern and that efforts are made to ensure it is used.

So what is the point of working with a pattern library of reusable design patterns? Well, you create an organisational standard for how things look and function. Besides obvious benefits around the organisation's identity, this form of standardisation can actually contribute to security among users. If someone ends up on a phishing website, they will hopefully get the chance to realise something is wrong, that something in the visual or functional identity is off. It is important to have a clear identity so that loyal users realise when something does not quite add up. If you do not work with a pattern library, you will be fully occupied with imitating yourself so as not to appear as a poor imitator yourself.

: Image 26: Prototype of a clinic search. A combination of several design patterns enables rapid prototyping.

Those of you who are a bit alert have already started thinking that some of these parts are included in what is sometimes called an organisation's graphic manual. The difference is that a style guide covers more than just the graphic. I would both like to claim, and recommend, that your style guide replaces your graphic manual. That manual can actually be included in the style guide, and what you call a graphic manual can instead be called a design guide. Complemented with the documented design patterns, you have come a good way with a style guide – visually at least.

Advantages of a pattern library (if it is used) are at least that it:

Ensures a uniform appearance. Through a reduced variation in how something looks, your design becomes more predictable for users. It is possible to keep track of whether a new design works better, the same or worse than the variant you have been running with previously.
Is easier to maintain in terms of how each design pattern works with the requirements you have, not least when you want to test them. For example, if a new device comes on the market, you can check that all your design patterns flow well and responsively even on the new device.
Evaluates prototypes more easily. When you have standardised design patterns to reuse, it is quick to produce a testable prototype. Just reuse what is not the new thing you want to evaluate (see the clinic search prototype shown here).
Delivers higher quality. If you ensure you maintain high standards for your design patterns and that they follow current best practice, you can count on new constructions maintaining a high quality. It is therefore important to set the bar high for what is included in the pattern library.

A common undertone in the above points is that it is probably resource-efficient in the long run to ensure you use your pattern library. To succeed, it may certainly require some encouragement from those who run the business, and a fair amount of hard work and interest from everyone involved.

Is a style guide not the same as a communications policy?

Perhaps it could be, but the goals are not quite the same. The difference is in how active the usage is and what status each documentation has within the organisation. A policy is probably more delimited and full of legal or bureaucratic jargon. A style guide, on the other hand, can be a living documentation with detailed tips and examples of how to proceed with digital communication.

In your style guide you can also include fluffier things. Like what values you have. Or like Mailchimp's style guide which has documented the encouraging language that is an essential part of the user experience with them.

: Image 27: Mailchimp explains their tonality in their style guide. That part of the service's experience can be about linguistic matters.

A style guide is preferably built as a small website where you can explore all the parts, see examples and get help to follow the organisation's best practice for designing something.

To get started with your work on a style guide, most need to start with an inventory of what is already documented within the business you work in and how it can fit into this new reality. If you have not figured it out already, a style guide is something that primarily has a top-down perspective, so if you do not work at the top of your organisation, you probably need help from colleagues to establish your style guide, or get permission to make your own, local, style guide.

Many surely already have documentation on how to address customers and recipients. This should be included in your style guide and then you can forget about that document. Let the style guide be the starting point for everything concerning communication, design for digital and print, as well as guides for how it all works in practice and whom to turn to for support or questions.

A style guide is as mentioned some form of umbrella concept for several things. To start describing the more “webby” things that are included in your style guide, you can talk about the style guide's basic elements, namely:

How the column and grid system works for mobiles and desktops.
Default appearance of common HTML elements. What do for example lists look like, images and their captions?
Typography around paragraphs of text, heading levels, fonts, etc.
How you handle tables, forms and so on.
Design questions such as colours, appearance of error and warning messages, etc.
Which icons are used for what and how they are placed correctly design-wise.
How media files are embedded.

A style guide should lead by good example when it comes to how web code is handled. It is a place for those who build websites to fetch code snippets so it is done correctly, straight away. If you have a well-developed style guide, it becomes easier to build a temporary microsite for a campaign, or if for some other reason you need to build a new website. Then developers can fetch quality-tested components, frameworks and ready-made code snippets, all of which are robustly constructed and accessibility-reviewed. That is the idea, at least – that you as a commissioner should be able to hand over your style guide as some sort of reference point for a supplier to relate to.

: Image 28: The style guide for Bootstrap explains how images become responsive, and specifies which code should be used.

The style guide should also explain what positions have been taken regarding design choices. Among other things, how old browsers you intend to support and any exceptions you have arrived at. Examples of such exceptions are how older browsers without support for media queries should handle a responsive reality, or if you have chosen to use the SVG format for images, that support is not great in old Internet Explorer. In the style guide you explain whether you intend to use any particular polyfill²⁹ to solve backwards compatibility.

Primarily this book is about the web, but of course a style guide can just as well include apps, social channels, etc.

To be honest, it is not even in web developers' circles that style guides are anything new. But the terminology has often previously been code manual or similar, still with the goal that you should be uniform in how you produce your output. For a developer it is of the utmost importance how you name things in code, partly for it to be explanatory for someone else who later needs to fix the code, but also to avoid the risk of clashes between things named the same. If you want to nerd out on this, check out the book Code Complete³⁰, if you want to tackle technicalities like naming JavaScript variables.

Depending a bit on whom you ask what a style guide is, you will get slightly different answers. If you follow bloggers in web design, you quickly notice that a style guide can actually be many things. What I got through at my workplace when we made our style guide concerns the following:

The organisation's web standards, values and ambition. For example, how you view accessibility, how code should be written, and more.
A library of design patterns for the web and other digital channels. If you have ever changed a theme in WordPress, you have certainly seen how they choose to present the theme. You get to see things like typography, how images are displayed, and more. You get an idea of how different parts of a website might look.
Performance budget, and here we should not take performance literally. The English term is performance budget, so possibly we should also include everything that has to do with results.

I want to clarify that none of the above points are in any way mandatory in a style guide; you can do pretty much what you want with your own style guide. But for this book's argumentation, you can count on a style guide covering at least content, web design and performance budget. The above points were what I got buy-in for where I work, a place where very few had heard of a style guide before. Which perhaps can be taken as a sign of which parts are comprehensible in a wider circle of people who all work with the web in one way or another. What did not make it through the eye of the needle in the style guide's first version was the web editors' handbook; they wanted to have it separately – possibly because they could not see the style guide being used or being of interest further out in the organisation.

The style guide is probably primarily for content producers and perhaps those who own the website from a management position. It should address what creates the conditions for a website to deliver results. If you want to point out an owner of the style guide in a larger organisation, it is probably the marketing manager or communications manager who should care most. And those who maintain the style guide's content are those in the corresponding department, possibly together with those who develop the website.

A style guide should not be a document you stash in some archive. Rather, it should be something you work actively with. Style guides are often called living style guides in English. It is meant to be something living, something changeable. The point of your design patterns (which make up your web design) is that they continuously need to be improved to live up to the web's constantly changing requirements and users' expectations.

If you need to refer to an authority to be allowed to work with your style guide, go with Brad Frost. His concept of Atomic Design we have mentioned previously. It is a logical component-based approach to web design. It offers an explanatory model from the smallest conceivable component, such as a search button, up to what an example page can look like.

Examples of questions to address

There are a number of questions to answer when you set your ambition level in a web project. Depending on which professional group you align yourself with, you can call this ambition different things.

Style guide is perhaps closer to the content producer's view of ambition level, while performance budget is the developer's angle (but increasingly of interest to those who want to convert their users). I suggest we consider the performance budget as an appendix to the style guide. It is after all about the organisation's communicative style in digital channels and performance is very much an important part.

A style guide often contains examples of typography, design, tone of voice and more, while a performance budget often focuses on measurable things that are quantifiable. Things that can be analysed and sent as measurable requirements to suppliers. For example, how long is acceptable for receiving a web page. Together with the visual identity, the organisation's tonality in language, a “technical” identity definitely belongs to form a unified experience. What you can expect from your organisation in digital contexts; more about that you will read in the upcoming section on performance budgets.

A bonus question we at my workplace got around the style guide includes the privacy review within the public sector that Dagens Nyheter ran as a series of articles at the same time as we developed the style guide in autumn 2015. It became a discussion about what values we had, whether our convenience in choice of tools and integrations could outweigh the users' privacy. The question arose about whether the public sector should ever have third parties on their websites if you do not have a handle on any consequences for your users. It can be much more than whether you should have Google Analytics. It also applies to how websites are designed, whether you use external font services, embed the Facebook feed, social share buttons, and more.

Furthermore, the website's style also has to do with usability around the content. Whether the length of page titles works in all conceivable contexts, how you view responsive image handling and much more.

These were the questions we had at my workplace when we first started working with our style guide. Some of the questions are surely relevant where you work too. A test of whether a question is meaningful to include in the style guide is the “so what test”, meaning being able to answer “So what, who cares?” You need to be able to have a factual discussion around each point you choose to include. Who it is for and why it is important.

How should our typography be to guarantee a good reading experience on all platforms?
Should we embed third-party services that potentially threaten the user's privacy?
Length of page titles. At most 60 characters?
Should images be displayed in retina resolution or “regular resolution”?
Allow decorative images, or not?
When is it justified to use tables?
Should all important pages specify a meta description and at least one keyword (something our own search engine needs for site search to work well)?
At least one call to action visible without scrolling on landing pages? Visible for all kinds of devices in use?

Maintaining the style guide

A challenge you must try to handle through the work with your style guide is how it should be maintained over time. Just as guidelines for social media, and other fast-moving things, can become comically outdated quite quickly, it is important that the style guide does not become something you stash in a desk drawer and look at every other year. Even though I think one person should be appointed as the style guide's maintainer, the style guide should be everyone's concern. At least those who work with any form of communication or development in digital channels.

Pattern libraries provide clearer requirements for suppliers

As a supplier, a style guide can make it easier to understand what expectations exist. And that you do not need to reinvent things like which responsive behaviour you have used previously and other things that should reasonably be standardised within the organisation that created the style guide. This also ensures a consistent experience between different websites from the same organisation.

: Image 29: The web framework Bootstrap's style guide is also its documentation.

An incredibly frequently used (and mocked) standardising framework for the web is Bootstrap. Their documentation is exactly what you could consider a style guide. There you can learn exactly how code should be designed to live up to the design convention mobile first. How forms both look and should be coded, and everything else that has to do with interface code like HTML, JavaScript and CSS.

The reason Bootstrap is mocked is that its enormous impact has made very many websites look similar. Sure, it is perhaps not a designer's dream to be forced to relate to an appearance that is common to all kinds of organisations. But this consistent design is precisely what we are after when the sender is one and the same organisation.

Most basic in your pattern library is how the most common design elements look and respond responsively, for example how the header responds to the different sized screens users might use. This is one of the biggest points of a style guide and its pattern library. That you can both test how it works today but also be the place where you in your active management of the style guide can develop new design patterns and ensure they measure up.

It is perhaps not reasonable to think that you will take the time to run every single little design decision through this process and get it documented. Furthermore, it probably takes a fairly large investment of time and money to reach a good level. When I scouted the market in spring 2015 to commission this for my employer, it was clear that none of the suppliers I spoke with thought it was worthwhile to spend less than 200 hours on such an assignment. Their time, that is, as experts in web design and interface programming. I imagine that we as commissioners would probably have had to put in at least as much time ourselves. For those hours you would get the most common design components into your style guide's pattern library section. That is, the following parts of a website:

Overall responsiveness, grid system and outer frames for the appearance.
Basic typography.
Header, its parts such as logotype, search field and main navigation.
A few components within a page's unique content. You could probably choose to get your start page well-made, plus an example of a subpage that is heavier on text.
Footer, with its contact details and more.

There is no real upper limit for what should be put into the pattern library. To prioritise and start tackling this work, Atomic Design helps. Looking at the smallest building blocks and in which combinations they can occur on a website.

Some examples of such atomic design patterns can be:

Image carousels (that abomination of a compromise to silence everyone who demands that their content should be on the start page).
Presentation of calendar events and happenings. Can be both in compact list form and also what the page template looks like.
Search suggestions that appear when someone has started typing keywords in a search field.
Mega menu. You know those large expandable menus that can contain multiple columns of lists of subpages, related content, and more.
Map features and embedded video clips.
Slightly more complicated forms, visualisations and tables, which can contain features like filtering and sorting.

When a pattern library exists, you can combine these design components into complete example pages. Then it becomes easier to get a feel for the appearance.

: Image 30: Code for America's style guide shows examples of what a page can look like, with some selected design patterns.

What you need to document alongside the pattern library is how the process works for getting a new design pattern included. What requirements they should meet, how they should be tested, and more. Hopefully obvious requirements are that it should be accessibility-tested, validate the chosen code standard and be compatible with the pattern library as a whole. What is included in your style guide should be the organisation's best practice for digital communication, so it is important to set the bar high.

: Image 31: Starbucks' style guide shows the design pattern for how warning messages should look.

An example of a scenario around this, which I myself worked on, is that we prototype-built a small search function directly in the style guide. The alternative would be to do as usual, basically send a long list of requirements to our web developers and then they would have built a prototype directly in our publishing system. Instead we brought in an expert on web design and extended our style guide. This meant we could hand over something very concrete to the web developers (whose greatest strength may not be conceptual design) to build into our CMS. In other words, we had already sorted out exactly how it should look, function in different types of devices, exactly how the interface code needed to be, done usability tests on live users, and tested accessibility. So the assignment to our web-savvy system developers became very concrete – “do exactly as shown in the style guide, make it work in our website”. In this way, everyone does what they are best at.

Browsing should be as simple and fast as turning a page in a magazine.
- Larry Page, founder of Google

Performance budget, technical values and quality guidelines

I previously worked as a web consultant. My greatest role model in how to act as a consultant (and as a leader in general) is David Maister, formerly a professor at Harvard Business School. He has written the excellent book Managing The Professional Service Firm³¹. He often states the obvious that you have not yet managed to put your finger on.

One thing he addresses is highly relevant to performance, namely how a service or product is perceived by its users. The whole thing is of course fairly subjective since everyone has different expectations in advance. He proposed a formula that I may have somewhat mangled in my translation, namely:

Satisfaction = Experience – Expectation.

The way I acted on this, as a consultant, was to always try to over-deliver a little. It should always turn out a bit better than expected. Give that little extra (abbreviated DLX). There was plenty of joking about what DLX would be in a specific project, but that it was important we all agreed on. Developers suddenly started talking about our customers' experience of our deliveries. That was a good thing.

Underpromising – overdelivering.

If you can influence the expectation, the experience itself becomes less crucial, but if the expectation is sky-high, it becomes almost impossible to do a good job regardless of effort. This is where a performance budget comes in – early in the process! If all design decisions have already been taken, the whole thing is built and you conclude that the result turned out far too slow – well, how likely is it that you can fix it after the fact? It is surely possible, but it will definitely be more expensive to try to fix something that is already broken. Smarter would be to think things through from the start.

What level should you choose? Do some research on what level your competitors or equivalent organisations maintain, and then make sure to surpass them just enough. Something newly built should surely be better than what is already established?

Supporting something does not need to mean a desire to optimise

In ancient times we often saw texts like “This website works best in Netscape 4.0 with a screen resolution of 1024x768 pixels on a 17” screen”.

What demands do you intend to place on your users and the equipment they choose? It is worth remembering that just because you intend to support a certain piece of equipment, browser, or device does not automatically mean you intend to go all out and optimise that experience. Think of support as something being possible to use, but then there are other cases where you consider it worthwhile to work on optimisation. In the performance budget you document this minimum level.

A design principle that we in the old guard of web developers have lived by, and which is part of the concept of following web standards, is usually called progressive enhancement. It means that a good basic function should be offered to everyone and if there is still engagement left, you can start optimising for the users that are most important to you, or have certain equipment that may need a little more care for it to work optimally.

The performance budget should more than gladly be included in the organisation's style guide. Primarily, the performance budget is aimed at developers. Everyone else should not have to talk technology, but it can also work well as a clarification of the organisation's expectations on its suppliers. Strive for the performance budget to provide enough ammunition that non-developers should be able to counter with the question “does it comply with the performance budget?” on every technical question. You cannot expect everyone to have reason to know all the components of the performance budget.

This document can be seen as a guideline around the website's quality and minimum acceptable level in a range of areas you specify, for example accessibility. The performance budget should preferably be launched in a formal way so that everyone involved understands that from now on there is a measurable reality to relate to. That it applies to the web developers, IT, the editors and everyone else who affects the website. Personally, I think you should also make it publicly available on the web; then it becomes even harder to ignore or forget.

You might wonder what the point of a performance budget is? Your performance budget is your way of clarifying the organisation's service level in digital channels, but also the measurement points you check when you do your recurring content audit. Such as page titles being an appropriate length, etc.

If you wonder whether web performance actually matters, you will soon get proof in abundance. But if we for the moment settle for the utterly objective and quantitative way of looking at it, I can refer to a study that Walmart has done. They have found a very clear correlation between the loading time of a web page and how well those users convert, that is, users doing something desirable on the website.

: Image 32: Walmart has found a correlation between performance and conversion.

It is always worth reminding yourself that with performance you should also think of the word achievement, broadly speaking; it is not just about speed.

Example of a performance budget

Below you can see the points we selected at my workplace for our first performance budget³², which I developed for Region Västra Götaland in 2015.

Beginning of quote.

Performance budget and measurable web quality for www.vgregion.se

This is initial documentation and agreement for the project to upgrade to Episerver CMS and the new interface.

Read the requirements below as being measured with representative content on test pages the developers create before review with the project's designated web analyst. These test pages should not be significantly affected by VGR's editors between test occasions; they should be comparable over time.

A delivery that fails these requirements should not be put into production and should not be accepted by VGR.

1. Values, priorities and performance for the entire website

Follow the design conventions progressive enhancement and mobile first, meaning focus on accessibility first and finesse later, and that it is the mobile scenario that sets the needs for design and function.
Function before form, and the experience above technicalities. That is, inclusive design, both for the ability of people with disabilities to participate but also to reach as many types of equipment as possible.

2. Measurable performance budget

Max 399 KB for a page view.
Under 3 seconds for complete page load, measured from a favourable wired connection.
Under 10 seconds for complete page load measured on a 3G connection.

3. Minimum level for web

These points describe the lowest accepted level for the first iteration of www.vgregion.se; this level must not be degraded during future updates, rather these requirements should be tightened continuously in consultation with the developers.

All templates/views/components on the website shall at the very minimum:

Be tested and secured against WCAG 2 level AA.
Be considered mobile-friendly according to Google's mobile-friendliness test.
With example content achieve at least 85 out of 100 in Google PageSpeed with mobile settings, and at least 90 for desktop.
Max 2 CSS files loaded.
Max 3 JavaScript files loaded.
Use CSS Sprites (or equivalent technique) to reduce the number of image files to download.
Structural CSS code included in the HTML code according to good performance practice for fast initial display of content.

End of quote.

Yes, this was what we agreed on internally and together with our web consultants before the project. You might wonder how it went? Well, the first version of the performance budget I worked through at my workplace has set the absolute requirement to follow the accessibility guideline WCAG 2.0 at minimum level AA. That should hardly be controversial given that poor accessibility has been considered discrimination by law since 2015 and since 2016 is something the EU has decided is mandatory for all public authorities – then including intranets and extranets.

Also some goals for how quickly it should be possible to download a page. There came a sudden awakening in the design work for our upcoming website that you cannot be as wasteful as you like with decorative elements. We have set the limit at 399 KB and then the editor should have at least 140 KB available to be able to upload a heavier image.

One point that had to concede in the first version of the performance budget was a value about “Safeguard the visitors' privacy. No third-party services whatsoever, for example Google Analytics, social share buttons, etc.” That issue needed to be handled separately. But the value as such regarding privacy was still present in other documents, including the IT security policy.

: Image 33: The graph from Pingdom shows that a deployment of new code in mid-March made the website on average 0.3 seconds slower.

We started measuring already during the development phase. An interesting finding was that an update to the future website made it on average 0.3 seconds slower according to Pingdom's tool for measuring response time. I think that is a finding because you can now talk numbers instead of subjective gut feeling. In this way you have the opportunity to weigh pros and cons, whether the new features that were introduced are actually worth 0.3 seconds of slower response time. Perhaps they are, but you cannot add 0.3 seconds of extra response time to every single update. Sooner or later you will hit the ceiling for the page load time you set up in the performance budget. By having a long history of data, you can have a better basis than otherwise for what you think needs to be addressed to not constantly worsen the situation.

In our case, I coldly count on us being able to throw money at the problem and buy more hardware, but at the same time we had a large-scale cache solution in the works that the IT department was excited about. It should at the very worst halve the time for displaying the pages.

But there are of course lots of other questions where it can be useful to specify your ambition regarding performance and results in advance. Obviously, a website of today should be considered mobile-friendly. In that there are many things you need to measure, both the design broadly but also what ends up on the website. We have specified this to both Google's testing tool considering all types of templates in our publishing tool to be mobile-friendly, with some form of example content. This is the requirement on those who build our web. Then it becomes a matter of following up that the editors do not squander that experience by inserting extra-wide tables and so on.

Continuously measuring the quality of the web page

To be clear and predictable towards our suppliers, we have jointly set up test pages. These test pages should score at least 85 out of 100 according to the tool Google PageSpeed, with mobile settings. For a desktop it should be at least 90 out of 100. These figures they should check already before they deploy anything new. It is not acceptable for anything to worsen the score. At the very least, nothing that has not been justified should be allowed to worsen the score.

The reason it is specifically 85 out of 100 is because Google set that as the level when they consider the website to be well-constructed. We would like to live up to this level as it is not entirely unimportant what Google thinks of your website if you want visitors from their search engine.

We have also set limitations on the number of files required to load a page. The reason for this is that for every file that needs to be downloaded there is a waiting time; the more files, the longer the total wait for the page to finish. This is not a particularly big problem under favourable conditions when we sit at the office, but you can really notice the difference when you are on a shaky 3G or Edge connection out in the countryside. I, who pick an awful lot of mushrooms, notice this when I take a break and casually browse a bit. Then imagine if you have a more important errand than reading an article on The Verge. Like finding out the number for the poison information helpline, or doing an image search for which mushrooms you should not taste?

Do not take our figures and requirements straight away for use at home. Have that discussion with your supplier about what is a reasonable ambition on the platform you have. Perhaps you should put in the effort at the next major intervention on the website rather than polishing what is about to be redone.

The point of establishing a list of performance requirements for your style guide is to have some measurable way to ensure that your website does not deteriorate over time, or after launch. Rather that it continuously improves with each update.

A list like this performance budget can supplement the test protocols that web developers have, at least for larger websites, to verify that a web project meets the right quality. Furthermore, many of us have checklists for the communicative aspects, that is, how the tone should be and what writing rules to follow, which means this becomes a natural part of the continuous follow-up and reflection on how the website is doing. If there is no designated web analyst, it is probably a web developer you need to compile the report on how the website performs, or if you just choose tools like Pingdom that most people can manage themselves. We will talk more about specific tools in the next part of the book.

If you run a larger website, it is a good idea to take an interest in what tests the developers have to assure you that the right quality is achieved. These tests can be anything from completely manual to fully automated. Some of the points in your performance budget are affected by the workflow that web developers have and some of the points are easy to solve through configuration of build servers. Like Jenkins, or other tools, which many use for continuous delivery as many deploy updates to the website – up to several times a day.

: Image 34: More and more people 'deploy' updates to their web systems daily.

But why is performance so damn important?

There are many who have researched performance (here read as speed, not necessarily as in achievement). Primarily you tend to refer to Nielsen-Norman Group³³ who have divided it into three parts, namely that the user at:

0.1 second response time stops perceiving the response as immediate.
1 second response time begins to have their thought flow hindered by a perceived wait.
10 seconds response time the user has difficulty staying attentive and wants to do something else in the meantime.

In other words, you cause a cognitive burden on all users who have a slow experience. And as Walmart has shown, a slow experience is less useful in that users to a lesser extent convert. More evidence for the connection between speed and usefulness is coming shortly.

When Google redid their not exactly earth-shattering social network Google+ during autumn 2015, they set a hard performance budget.

We hit our goal of never downloading more than 60k of HTML, 60k of JavaScript and 60k of CSS at any one time!
- Google's Developer pages³⁴

Google+ went from having had 22.6 MB of weight on its start page to 0.3 MB (HTML and images). From 251 files that needed to be downloaded to only 45. 2.77 MB of JavaScript and CSS to 0.11 MB. For load times, they went from 12 seconds on average down to 3 seconds. Furthermore, they trimmed off the fat by going from 0.7 seconds for the user to start receiving files down to only 0.1 seconds, so-called time to first byte (TTFB).

Speed is irrelevant if you are going in the wrong direction.
- Mahatma Gandhi

As if that were not enough, there are plenty of studies showing the connection between performance and how useful the user's session has been. These organisations have shared what happened with their services when they improved speed. See performance references at the end of the book, for example:

Google: 2% slower = 2% fewer searches per user
Yahoo: 400 milliseconds faster = 9% more traffic
AOL: Faster pages = more page views
Amazon: 0.1 seconds faster = 1% more revenue
Shopzilla: 5 seconds faster = 25% more page views, 7 to 12% more revenue
Aberdeen Group: 1 second slower = 11% fewer page views, 7% fewer conversions.
Gomez: 75% of users in web shops would rather leave the website for a competitor than patiently wait.
Tagman: For each second of slower load time you lose 6.7% conversion; interestingly enough, 1–2 seconds load time converts best, not the fastest (see graph below).
Etsy: 160 KB of images increased the bounce rate by 12%.

As icing on the cake, Google includes web performance in its ranking algorithm, so if you do not want to fall behind in search results, perhaps that too is a carrot to fight a little extra with performance.

: Image 35: Tagman measures conversion level based on how long the load time is.

For those who prefer to read academic reports, check out the references at the end of the book to find examples from the 1960s to today. There you will also find links to the above facts; there is more interesting material to be found in those writings.

What early lessons are there from Region Västra Götaland's work?

At my workplace we have completed our first project that had to relate to a performance budget, namely our upgrade of Episerver CMS. It is a fairly extensive and complex project. There are masses of stakeholders high and low in the organisation because what is being produced is a common foundation for all the different administrations within this very large organisation with many widely different areas of activity. The common web template is to form the foundation for about ten fairly large websites for our different hospital groups, primary care, dental care and some cultural websites.

Now I am of course somewhat biased, but I perceive that colleagues and consultants after a while started appreciating the concretisation that the performance budget contributed to certain questions. Our web consultants have even expressed that they are enthusiastic about this. That delights me enormously.

1. “Let us go with this unique font, it makes the whole thing look better”

Another useful concretisation around design came when the question of special fonts was in line with our performance budget. The values around privacy sharpened the discussion around custom fonts in a rewarding way, beyond what had to do with performance. It turned out that beyond an annual subscription cost for having a custom font solely for headings, we needed to include an external CSS file to let the font seller keep track of how many page views we have. The advantage of this font was obvious – it looked good. The disadvantages became, thanks to the performance budget, also clear and could stand as a counterweight in our internal reasoning, namely that:

We were forced to have a third-party file on all our page views. That jeopardises privacy in that you do not know who else is listening in on that communication. If you are orthodox about the cookie law, we are not allowed to use third parties in this way, at least not without active consent from each user, this before the font is downloaded and applied.
An extra file needed to be downloaded, without any direct benefit for our users. We had set 2 CSS files as the limit – should we then sacrifice one of the two solely for an external party wanting to monitor that we did not overdraft the number of page views we had paid for a font?
To cover the different variants of the font, such as italic, bold, etc., up to 4 files needed to be downloaded to the users. Under less favourable conditions, these files can take a few seconds just in pure waiting time regardless of how small they are. In other words, you could blow the budget's intended maximum time for download just with these files.
The font files would total approximately 80 KB. In total for an entire page view we had set a limit of 399 KB. In most page views, this peculiar font would have been shown on 2–3 headings on an entire page. Was it then worth it that 20% of the total weight would go to this? Were there other fonts that could get the job done with less impact?

So the question became quite clear. Was it worth it for a peculiar font? Initially the answer was a resounding no. Georgia would have to do; it was already available in practically every single one of our users' devices, entirely without the disadvantages that the performance budget made so obvious to those involved. In other words, it did not become solely a question about design, typography and whether the cost was okay. The discussion had a highly tangible consequence against the performance budget. In a future world where best practice changes regarding how we handle visitors' privacy, it is not a given that third-party involvement would even be allowed.

The answer to the question was that at least for the time being, custom fonts would be avoided. If we find a solution with less impact on performance, perhaps the decision will be different.

2. Header background vs contrast ratio

Utterly fundamental for good accessibility is having a contrast ratio between foreground and background. You notice this not least yourself when trying to use your mobile phone in strong sunlight outdoors.

The reason it can be difficult to live up to good contrast between text and background on a responsive website is that things are not fixed in their position. They kind of move around a bit depending on what space is available. So in our first design proposal, we had not arrived at a solution that did not negatively affect those with reduced vision, and therefore there was no background image. Here we also came a bit into conflict with the graphic manual as it required this background image, something that is not a problem with print materials through their fixed layout where you know exactly where things are placed. This became a useful exercise in discussing design and perhaps pointed to the need for a more digital perspective in the graphic manual.

Combining background images in a responsive header and guaranteeing good contrast turned out to be a tough nut to crack. Since we did not feel convinced that this could become both beautiful and accessible, the header's background image disappeared with reference to compliance with the accessibility guideline WCAG.

These subtle nuance differences that many designers are often very dependent on do not work very well anymore in a mobile reality. At the same time, they have never worked particularly well for those with reduced vision; only now are the rest of us discovering it too.

A related anecdote was when an art director was going to show what he had designed for us. Since the nuances completely disappeared the way the projector showed it, he apologised and explained that it looked better on his screen. That does not help. We cannot expect all users to have an outrageously expensive Ultra HD screen that is colour-calibrated and has perfect contrasts. People check our websites on their half-battered mobile phone, outdoors in the middle of the day at Midsummer in strong sunshine. We just have to get used to it; the past is not coming back.

3. How to fetch external news sources?

I have many times irritatedly exclaimed “how hard can it be?” when something felt obvious and simple. One such question that seemed simply solved appeared in a different light due to the performance budget's goal of page load time.

There is namely a need to aggregate one or more external news sources (via the technology RSS) and display them as a news column on your own website. The worn expression that no chain is stronger than its weakest link is clear when you mix in multiple parties to be able to display your web page. For example, how do you handle it if one of those external news sources is not up, or responds only after 10 seconds? Such things happen. Not least during a societal crisis these problems can start showing up, but it is enough that either your or their websites get an increased load for your website to go down.

If the website is to display itself in under 3 seconds, you just start adding up the response times of the number of external sources you make yourself dependent on. There is probably no reason to be certain that all of them together are guaranteed to respond in less than 3 seconds, and then you have already spent almost your entire budget for page loading just on this function.

We have not arrived at a crystal-clear solution yet that is a reasonably sized expense. One alternative that IT investigated is whether you can use some technical solution as an intermediary between the websites and the news sources to be monitored. Then you can for example try to isolate waiting and error handling to software that is good at that task, or at least better than our CMS.

By introducing an intermediary for just this problem, perhaps you get a truer cost estimate, so the rest of the website does not have to bear that cost. The specialised solution might be designed to wait a maximum of 0.2 seconds for a response from the external sources. And if you get an isolated price tag for just this function, perhaps you conclude that news is so important that it is worth it.

How to get acceptance for performance work?

There are probably many challenges in selling the need for performance work, especially if those it concerns do not have a culture of measurability. I myself have encountered some resistance, sceptical colleagues and participants at conferences where I have lectured on the subject. It is healthy to be sceptical, even about this. But I thought I would offer some tips on what motivations I think you can find among those you need to influence.

A web-developing friend, at a non-involved web agency, commented on why he would like to deliver in accordance with a performance budget like this:

When someone sets requirements, it means they care and value the result.
- Filip Dalväg³⁵, frontend developer at the web agency Netrelations

I think many developers agree with Filip, at least as soon as they understand what it is about. Practically everyone wants to do as good a job as possible and this is a yardstick for good work that developers can easily take to heart, since it is written mostly in their language. Then it is absolutely not the case that there would be consensus about exactly what best practice is if you ask two different developers. Many choices are things that are a judgement about what you think gives the most benefit and it is easy to end up in near-religious discussions about right and wrong in how you believe the craft should be done.

The point of having this discussion among the developers, or with your agency, is to try to reach a consensus about what is good, and then you document it as the developers' proposed performance budget.

For everyone involved in developing or managing a website, you may need to ensure the following activities are carried out, possibly in this order:

Evangelise the message that as a group you can do even better, and show references about what difference performance can have for the website to contribute even more value to the business. For goodness' sake do not forget the coffee and pastries so people stay awake! :)
Arrange lectures, lunch meetings with discussions and educate people in the subject.
Workshop a first draft of a performance budget. Participants need to be those who know operations, development, design and those who follow up the business's benefit from the website.
Communicate the performance budget! If not all concerned know about it, not much will happen. Make sure everyone in the website's “from start to finish” chain knows about the performance budget and has had the opportunity to express any reservations about how it is designed.
Ensure there are tools for continuous follow-up; this is something we who work specifically with web analytics need to do regardless of whether we have started actively improving performance. In my case, as the manager of our performance budget, I plan to check our compliance once per quarter, but many performance budgets will probably be designed so that follow-up can happen automatically all the time.
Give attention to the people and teams who succeed in improving performance on the website. As a consultant, I myself used to often acknowledge my team's successes by buying a sandwich cake and dedicating the celebration to the person who had made an effort that impressed me.
Keep up with developments. What is best practice in the web changes fast, and with it also what you do for good performance. One question is how a transition to HTTP/2 affects the performance optimisation that has been done. More about this in Part 4 of the book.
Communicate changes. The performance budget will need to be managed and updated. I myself have planned to review the one we have at my workplace annually.

At my workplace I did all the above myself. As a former web developer, perhaps I had it a bit easier than many other web analysts to take in all the details about performance optimisation, but primarily my previous experiences made it easier to defend and motivate certain choices. It took a few months, then our web consultants started schooling me about new things they had learned. Like round trips over the network, since everything is sent in 14 KB packets, and they had suggestions for how we could do an even better job. Somehow the competitive instinct was ignited about how they could overperform. I like that sort of thing.

To get decision-makers on board that this is worth putting some effort into, it can be successful to first do a competitive analysis. Then you report how you stack up against the competition and what concrete activities you should tackle to become (even) better. There are loads of tools for this and several of them we will look more closely at in the following parts of the book. A visual, and therefore very pedagogical, way to show the difference between your own website and someone else's is Webpagetest.org's function Visual Comparison. There you can add one or more websites to see how visually complete they are and compare them with each other.

: Image 36: If you compare Aftonbladet with Expressen, Expressen is much faster at showing its content on a slow mobile connection.

Let us say that you are worse than your worst competitor; that should be motivation enough to get a mandate to start acting and with it an appropriate budget. It is the web analyst's job to investigate whether sufficient reason exists to work on performance, but also to be able to follow up that each effort is worth the trouble.

Continue reading – Part 3: Web Analytics: Deep dive