Chapter 3: Web design

In recent years, it has become clear that we have no control over how our visitors choose to connect to our websites. They can enter through anything from a mobile phone while sitting on a bumpy bus to a giant TV screen while surfing reclined in the living room sofa.

It is not just the size of the screen that matters but also how your visitors control their device, the connection speed and the maximum definition the screen can display.

Besides satisfying the visitor whatever their surfing situation, we also need to design with business goals in mind so that not all design proposals are assessed only using subjective measures. Do not look at your website as a static brochure, neither the content nor the technology you use. Technology and content needs to, with increasingly shorter intervals, keep up to date for your website to be relevant.

The Web was created between 1991 and 1993. In 1993, Mosaic showed up – the first web browser. It was a very basic experience, with text that could run over pages. First in 1996, a competing browser appeared on the market in the form of Microsoft’s Internet Explorer (IE), a browser which supported the then-obscure technology CSS (Cascading Style Sheets) to separate content from its appearance.

Mosaic was soon renamed Netscape and competition with IE began in who had the most feature-rich browser. The norms to respect, or develop, the initial standards for the Web were quickly forgotten, with techniques such as Javascript, dynamic HTML, CSS and Adobe Flash. This gave the publishers of websites an enormous amount of extra work who frequently had to build several separate sites, depending on whether the visitor was using Netscape or IE. Sometimes the main website was in Flash with minor versions for Netscape and IE.

Figure 28: A computer from back when the Web was born.
Figure 28: A computer from back when the Web was born.

Today however, it is a little more orderly regarding standards. Partly because the industry has matured but perhaps mostly because there are so many variants of browsers, browser versions that support various technologies as well as those running on different types of devices. Many web designers’ solution for this was to revert to using standardized page designs, which meant that what was built worked on most visitors’ computers. Not to develop according to established web standards, or not requiring it when ordering a website, is a cardinal error in the current situation. Especially when it is the only way to have any hope for everything to work as intended in future devices.

There are many design strategies to adopt when building websites. I will discuss the most basic ones worthy to be inspired by, or even to follow by the letter. Some are universal for project success; others go into detail on how the design of the buttons should look in order to be understood by visitors. design principles

Around the world, the public sector has started to standardize how to do things in order not to waste time and energy on methods already tried and failed. The British Government is quite prominent in the area of open data and service design. The British have developed something that can be likened to commandments19 for designing websites and digital services. Even though this is a proposal for the public sector, it absolutely has bearing on any project that will result in a digital product. The principles fit perfectly into this chapter and as a reminder of things that sometimes does not seem to be so obvious.

1. Start with needs

The real user’s needs and not the organization’s should be the focus. What needs should the service as a whole and in parts support? You need deep insight into needs before any other form of work on the design of a service is meaningful. Though it is worth remembering that what users ask for is not always what they actually need.

Use the documented needs as categories to organize your efforts around, users after all come to the service with a specific purpose. There is no reason to hide away the solution to a need in some small body text when you should make this information stand out.

2. Do less

Do less and sometimes nothing at all. If someone else has already fulfilled a need, it is better to link to them instead of putting effort into becoming a late competitor. If you can offer APIs, it may be enough for someone else to design a service and then your organization can focus on its core business while saving money at the same time.

The principle also applies to how much to present in one go. A website is better if there are a few obvious choices for the user to decide what to do. Content needs to be placed thematically.

3. Design with data

Most often, a service is not designed without prior knowledge. It probably already has a counterpart in the physical world that can act as inspiration, to guide you when designing the first version of a digital service.

The first mail-order company that built a web service certainly took some inspiration from what worked in the past, offline. This knowledge, together with A / B testing allows us to learn methodically from what works on actual users. A / B testing is about playing out version A against version B, and the version that performs best is the one used up until the time you want to test new contenders.

4. Do the hard work to make it simple

When designing a service, it is a good idea to take a fresh look at what needs to be done and not choosing the most obvious solution to get the decision out of the way. How difficult must this be? A quick job risks causing complexity for your users – if you cannot make it as easy as possible, your users will suffer, paying with their time and energy.

There are many examples, not only within the public sector, when one needs to have worked for many years within the organization in order to navigate to the right information. Would you bet a month’s salary on whether your employer has placed the request forms for leave under the category human resources or finance on the intranet? Probably not. To not be aware of our own sender-perspective is normal and it is remedied by calling in an external third-party who will not fall so easily into this trap.

5. Iterate. Then iterate again.

The best way to build a service is to start small and continue with constant updates and improvements of the service, based on responses from real users.

A service or website is never finished. If someone thinks otherwise, ask that person to explain themselves since it is probably an idea in need of rejecting. Shortly after celebrating the launch, it is already time to release the first update. These updates should also apply to web design, graphic design and identity in general and not just error correction. Major redesign projects tend to confuse visitors as does replacement of user names and passwords. Doing a comprehensive project suddenly, after a couple of years, should not be necessary as it could have been done little by little and one step at a time.

6. Build for inclusion

Including everyone from your service is a good idea. It is all about prioritizing readability, going beyond subjective design thinking such as allowing too low contrast text making it difficult to read. Make sure clickable areas are large enough so that visitors can use standard equipment, and, yes, you are supposed to follow design conventions. Technically, there is a lot to do but thanks to the accessibility guidelines WCAG (Web Content Accessibility Guidelines), everything is easy to understand and suitable levels can subsequently be chosen.

Those who have disabilities, and unfocused users in mass-transit, should be able to use the service.

7. Understand context

It is not about designing for a screen or building a service, but about designing for people to be able to use the service in their normal everyday context. That context can be mobile without a mouse, at an information kiosk or at a library and it may be that they do not have the assumed Facebook account to access the services put behind social networking walls.

The service should be usable in all imaginable, and even some less probable contexts.

8. Build digital services, not websites

Not everything revolves around your website. The solution to a need may well start on the website but finish at the nearest post office to the user – this needs to be considered in the design even though some factors are beyond our control.

It may be that a website is not the best option. Perhaps there are other digital opportunities that would fare better?

9. Be consistent, not uniform

As far as possible, use the same language and design layouts since this facilitates recognition for a user. When it is not possible or suitable, then you should make sure that you are at least consistent in your design.

For natural reasons, we cannot have a mobile service look identical as for a large computer screen, but you should effortlessly be able to see that it is the same organization and it should work in a similar way without the user having to learn new things.

10. Make things open: it makes things better

If possible, have an open policy, and share both the experience and the results of the work. Share code, data, design, ideas, failures and goals. In this way, you can get more people to examine what is created and you can get insights from others who also have an interest in achieving the best possible outcome.

Even if the project is not released as open source, we have probably all learned from others’ experiences and we should share our work. It’s an integral part of the Web to share with others and even if there is not tax-payers’ money for the project you are working on, you too can benefit by sharing.

One common problem on the Web is that things get overly complicated. Overdesign or other features that do not put the user’s needs first. The next design principle, KISS, covers how to relate to design for simplicity.

Keep it simple, stupid – KISS

A design principle created by the US Navy in the 1960s after they found that most systems work best if they stay simple rather than are allowed to become complex. Therefore, simplicity must be the primary design goal with avoidance of any unnecessary complexity at all costs.

According to this principle, a user can hardly be at fault and if they are not successful, those who designed the service screwed up. Often KISS involves not making a change or adding a feature, not allowing it to become complicated. It should be applied to everything. What good are decorative pictures doing? That cool effect, is it necessary? Why have your own design for buttons and forms when users are at risk of not understanding what it is?

If you make it complicated for users, technically, chances are that also search engines are prevented from indexing your website. If it becomes difficult for the search engines, your website will get fewer visitors and then it becomes almost pointless to have a website – if you are not actively contributing to what is called the deep web, i.e., the part users do not reach via search engines.

Do not break the web

There should be no surprises for users, or violating the conventions they have learned. A common example is whether users can rely on the back-button in the browser when they are banking online, or if they are halfway through the process of checking out a shopping cart. Uncertainty arises if it is necessary to use any custom back-button on the website or if the one in the browser will work as supposed to.

Of course, the browser’s back and forward buttons should work as intended in all web applications. Unfortunately, it seems to be a matter of honor only among a very few developers to handle this and for some reason there often does not seem to be a written specification from the client’s side.

Take, for instance, the software giant Microsoft’s product Outlook, an e-mail system used by millions of users around the world – do you think that you can go back from reading an e-mail and end up in your inbox? Nope, not if you use the browser’s back-button and happen to be browsing with an Iphone. A button, without explanatory text, with a left-pointing arrow in the field above the browser’s own navigation buttons does work great, however, but for the love of God, do not use the back-button in the browser just because it works on almost any other website! 🙂

Figure 29: In Outlook Web Access, the browser's back-button does not work. However, the custom, white circled left-arrow above does.
Figure 29: In Outlook Web Access, the browser’s back-button does not work. However, the custom, white circled left-arrow above does.

It is pathetic to say the least, that instead of ending up in your inbox, you are sent right back to the login window. Microsoft is unfortunately not alone in this nonchalant behavior. If you are prepared to put up with much hassle, you can from now on try to reload pages after you send a form, or are in the middle of a web service process. You will surely notice that the bank complains loudly, you will get double orders of shopping carts and in some cases, you will get hassled if you really want to post a form you’ve never even seen, once again.

Everything essential on a website should work in all browsers, and whatever is used to interact with the page. Many years have passed since it was reasonable to assume that all users had a mouse pointer hovering over something. Despite this, many websites’ menus are still optimized for mouse pointers and sometimes they do not work at all with a touch interface.

Nor should we require that users have any plugins in their browser, certainly not to view the most basic content. Java in the browser (note, I did not write Javascript which is something else entirely) has for many years been a huge security risk, the Adobe Flash plugin has brought many computers to their knees just to show complex ads. Not to mention Microsoft which came out with their idiotic Silverlight plugin far too late to compete with the badly designed Flash after web producers had agreed for years that Flash was dead.

That a web page should work without what may be considered unnecessary features is a discussion with a lot of nuances. On an intranet, it is easier to get control over which browsers employees use and which extensions are automatically installed. But of course, the KISS principle also applies on intranets, so employees who are blind, or have other disabilities, are not discriminated against because of someone’s incompetence or indifference. However, we cannot be complacent; needs will change over time. Those who have worked somewhere where the organization standardized their web systems around Internet Explorer 6 know what I am talking about. It became extremely painful to modernize all systems simultaneously later on.

Not only does a website need to be easy to understand, it must also persuade and build confidence. The next design principle is about how design guides the visitor through the interactions needed to fulfill the website’s purpose.

Persuasive web designs (PWD) – design that convinces

Design to convince users to do what the publisher of the website wants them to do. An example would be to showcase the products that are about to run out of stock – which makes the visitor believe that they are getting a better deal than in reality – but also to show a page before they check out their shopping cart where further offers are displayed.

If we leave the often simplistic e-commerce examples, PWD may be used to display a layman’s version of a legal agreement rather than a link to the version filled with legalese. Right here the ethical dilemma emerges, as simplification, i.e. removal of the obstacle in front of the user, must be in the user’s best interest and not risk causing any unpleasant surprises. It may sound trivial, but believe me, not everyone will think the same way as you do. What you think is a fantastic offer can, with too much compelling design, make the viewer feel completely fooled.

It is all about lowering the threshold for decisions and guiding a series of micro-decisions towards the goal you have. Here the concept of dark pattern introduces itself. That, by design, you control what happens in a way that is not in the user’s best interest, or intention. It could be moving around buttons so the user happens to give an app a five-star rating in an app store, without warning, adding additional products to the shopping cart, or services sending e-mails to your contacts claiming to be you.

A somewhat milder example of dark pattern is that which is preselected in a form actually affecting the outcome. For example, how likely it is that a person donates their organs. There have been studies on several countries’ populations and there is enormous difference in the results. The answer is controlled by how the question is asked.

Figure 30: How opting-in, or out, changed the outcome of European's interest in donating their organs. Study made by Dan Ariely.
Figure 30: How opting-in, or out, changed the outcome of European’s interest in donating their organs. Study made by Dan Ariely20.

What differentiates Danes from Swedes, for instance, is that the question was presented to Danes in the form of ‘Check this box if you want to donate your organs’ while Swedes had to tick the box if they did not want to donate their organs. This is explained by the fact that you do not put much consideration or time to change a default setting and in this case, what happened were two diametrically different things if you neglected to check the box. Trust me, Swedes are not that different from our fellow Vikings on the other side of the Strait of Öresund 🙂

In order not to confuse visitors, or be too eager to convert visitors into customers, this checklist might be worth going through at each design decision, as well as when writing texts.

1. Be clear in everything

Clear about who the sender is, the purpose of the service, what to do and so on. Add what is most important first in the text and graphically prioritized. Writing headers rather than titles is important, as headers contain information about the content, rather than titles to classify content. Your headers need to be true, active and descriptive like ‘We work according to the methodology Scrum’ instead of ‘Applied methodology at our company’. What in the text needs to be lifted to the header to describe the content of the text?

2. Be very careful of what is the default setting

By what is the default, you control people’s behavior and if it is not in the users’ best interest, it can create unnecessary irritation that may not even pay off in the short term. When you design a button, you can lower the threshold by linguistic tricks such as using the less daunting text ‘Add to cart’ instead of ‘Buy this item’. If you measure these two options, it is likely that more people dare to put something in the cart compared to a click that directly means a purchase. Does it lead to more conversions? Go ahead and measure and you will know if it works in your case.

3. Visual hierarchy is important

Do what is expected for operations to be carried out, easily found and executed. It may be that a form’s submit-button sticks out more graphically than the button to clear the form. With color, size and placement, you reduce friction to post the form.

Does the user have to scroll first to find what the purpose of the page is, or is it obvious at a quick glance? Even on small screens? If a user does not instantly see the so-called call-to-action, a button for example, it reduces the chance of what you want to happen actually happening.

Figure 31: Dropbox clearly thinks signing up is more important than signing in, probably because existing users might be more committed to fulfilling their task, compared to newcomers.
Figure 31: Dropbox clearly thinks signing up is more important than signing in, probably because existing users might be more committed to fulfilling their task, compared to newcomers.

4. Focus on the common goal you and your visitor have

You have probably seen websites where all the navigational features disappear when you are in the middle of the process of checking out a shopping cart? It is for you not to be distracted and cancel the purchase. The purpose of the checkout is that the user, with as little effort as possible, should be able to make a purchase; this is a clear mission statement for any e-commerce website.

5. Try not to overexert your users’ attention

Design your website so it is as self-explanatory as possible. An example of something to avoid is to add useful links after a very long text as the chance that the links are found decreases the longer the text is. Such links may be of greater benefit before the text.

You have probably seen the all too common cliché pictures from stock photo sites where people from all over the world smile at the beholder. Those pictures are not meaningful and should not compete for space with something that is important!

Well designed PWD will be experienced by the user as a clear and intuitive service, which should be the goal of every website. At the same time, the sender’s purpose with the website needs to be achieved. Something else that should be an obvious goal for each website is that it presents itself as well as possible on as many conceivable types of devices. That is what responsive web design is all about.

Responsive web design

A website should be able to display itself and be useful on any device the user selects and make the best of it. The idea is to invest effort into achieving a good compromise for all types of devices your users might use instead of building a mobile website, a desktop computer website, a games console website, a projector website, and what evermore may come in the future in the form of equipment with a web browser.

Figure 32: How a non-responsive website looks on an Iphone 5S.
Figure 32: How a non-responsive website looks on an Iphone 5S.

We have already seen the situation with special solutions online in the era when we had separate websites. One in HTML, one in Flash, and sometimes you had to choose Netscape or Internet Explorer after selecting the HTML version of a homepage, just to get the correct style sheet. Some clearly stated what kind of equipment that was recommended, as if a user would switch browsers, or change the screen resolution for every website they visited. That was not exactly smooth, and today we have more versions of browsers and types of screens than ever before. Today’s websites have to adapt to users and responsive web design (hereafter RWD) is the concept where a single website aims to satisfy all types of users without a plethora of special solutions.

Before RWD broke through, it was for many years assumed that the user could see at least 960 pixels horizontally on their screen. These 960 pixels were then divided into the number of columns needed for the design. When the Iphone was released in 2007 however, the average man in the street started surfing the Web with a browser, held in portrait mode, that was only 320 pixels wide and 480 pixels high on a 3.5-inch display. Websites back then assumed that the visitors had at least a 13-inch screen with at least 1024 pixels in width and 768 pixels in height. A large screen in landscape mode as opposed to a smaller screen with a lower resolution typically used in portrait mode. On a smartphone, websites were viewed in a zoomed-out mode without the necessary sharpness for even a person with extremely good eyesight to be able to read the text other than, at best, big headers. It was not a great experience surfing with a mobile phone before RWD made its entrance.

Exactly as if the web would be printed, many designers approached their design like an artist chooses a canvas of a suitable size to paint on – the Web’s cloth was 960 pixels wide and with infinite length for scrolling. The notion that it is not possible to choose a suitable canvas to design a website is really the most important insight of responsive web design.

The mobile moment

Responsive web is not really a technology aimed at mobile customization of a website, even though it competes indirectly with the idea of having a separate mobile website, but RWD does keep the mobile visitors on the main website. If you build a mobile website, it still needs to be responsive for the simple reason that there is too much variation even among mobile devices to be able to make assumptions on screen size, among other things. The same applies, as always, on common desktop computers. Some of us use only a laptop with a screen usually 13–15 inches wide, others use a desktop computer monitor up to 30 inches, or use a TV.

The reason RWD hit it big around 2013 probably correlates with the fact that many saw the percentage of mobile users had increased steadily in their web statistics, in some instances mobile users accounted for half the user base. A responsive website is supposed to be device-agnostic, making it a useful solution in a mobile or small tablet scenario. At the same point in time, an sufficient number of web users had browser support for modern web standards, required for responsiveness.

What the web genius Luke Wroblewski named The Mobile Moment, i.e. when the proportion of mobile visitors is greater than those using non-mobile devices, occurs at different speeds, if ever for some sites. Examples in my professional life are the national healthcare website in Sweden,, which had its mobile moment in early 2013, depending on whether you count tablets as a mobile device. While our biggest hospital,, at the same time had around 90 percent of its visitors on desktop computers.

The elements of responsive web design

Responsive web is actually three different techniques in combination. The techniques themselves were not new, but their combining became a bit of a revelation when Ethan Marcotte wrote his article in 2010, on the website A List Apart21.

1. Fluid grid – let the design fill the screen

Grid-systems are hardly a new thing; the biggest difference is that with responsive web design, we specify width in relative terms rather than in exact pixels – relative to the space available on each screen, that is. On mobiles and other small devices, it is often difficult to accommodate more than a single column of content, which means that the different page components need to be stacked on each other in a long column. On a small screen, it is particularly important to use the entire width so that no valuable space is lost in unnecessary margins. On a bigger screen we can afford more margins without being wasteful.

Figure 33: Fewer columns when the browser-window becomes smaller.
Figure 33: Fewer columns when the browser-window becomes smaller.

2. Media queries – to adapt the design to the available space

With media queries, you can have breakpoints identified which makes for a customized design based on different screen width needs. At some magical points, the breakpoints, the page can display itself in a different way. For example, changing the number of columns depending on the content’s needs. It is common for things of lower priority not to show up at all if the space is too limited – decorating images for example.

Often, at least the start page is one big compromise where everyone with influence gets something important to them on the display. Via a mobile, most of what you are used to from a desktop computer is not visible at first sight. Therefore, the ranking or prioritization of the content is one of the more difficult tasks a web project faces.

Media queries is like grouping the screen-sizes and specifying how the design should behave within a range. It is kind of like planning for several editions of the website.

Possible examples of a set of media queries in a CSS file:

  1. @media (max-width: 350px)
    Instructions for small mobile screens.
  2. @media (min-width: 351px) and (max-width: 767px)
    Larger mobile screens and many small tablets.
  3. @media (min-width: 768px) and (max-width: 979px)
    Tablets and some computers where the browser is not set to full screen.
  4. @media (min-width: 980px) Tablets and computers where the browser width is at least 980 pixels.

In the above example, there are four alternative designs of the website. You can end up with four different size-customized editions of the website for it to support optimal content presentation.

Figure 34: Layout for a large screen. Note the ordinary top-menu.
Figure 34: Layout for a large screen. Note the ordinary top-menu.
Figure 35: Layout for a medium-sized screen. Now with a hamburger-icon for the menu, and no arrows on the featured image itself.
Figure 35: Layout for a medium-sized screen. Now with a hamburger-icon for the menu, and no arrows on the featured image itself.
Figure 36: Same design for a small screen.
Figure 36: Same design for a small screen.

We should not heedlessly choose three versions of the breakpoints as in one for desktop computers, one for Ipads and another for the most recent Iphone. It is not necessarily those devices your visitors are using. But, perhaps mainly, because there really is no way to show exactly how a responsive website will look. If you take anything away from this part of the book, take away the idea that it is no longer meaningful to select a canvas. The point of responsive design is to surrender to the fact that screen variation is too large given all the kinds of devices the content will end up on. Instead, we should set the breakpoints from when the content needs to be broken up to present itself well, in order to achieve the desired effect with users.

3. Flexible images

Not only is the grid fluid, but also image width is set relatively so that their size is scaled up or down in line with other design elements. This is an alternative to programming exact pixel dimensions. Often image width is set to one hundred percent of the available space and the height to automatically adjust to get the correct proportions. This is fine on your own website, in a context you control, but just like any other content, images are reused in other contexts. Images are in fact often reused on other websites along with a link to the page the image is displayed on. A context that you have as little control over as the size of screen your own users happen to have.

Figure 37: Photo dominating on large screen.
Figure 37: Photo dominating on large screen.
Figure 38: The same photo shrunk to fit a mobile device.
Figure 38: The same photo shrunk to fit a mobile device.

Many have designed their newly built responsive sites with decorative, inspiring and awesome pictures. Many images are huge, not only in space but also in file-size, because the same image is to be displayed over most of the screen for some visitors and scaled down to appear on a small screen. A large picture becomes very heavy for it to have any image quality. It is especially difficult if there are people in the picture since we are sensitive to image optimization side effects on areas with human skin.

I can only guess why designers went for huge images but I think that with responsive technology, it was easy to get the design to work so well with leading images and image carousels. That and the fact that too many designers completely forgot that not everyone has a high-speed connection to the Internet as we do when at the office. Even community actors, such as municipalities, which are expected to serve the public through their websites, were blinded and used such massive images that homepages could sometimes weigh 10 MB. That can amount up to two percent of a mobile’s monthly data plan for some mobile users, consumed by mostly meaningless image carousels.

Depending on who you are talking to you will hear about lots of other things that are included or not included, according to them, in responsive web design. The points above highlight a number of challenges that we need to take care of – among other things that the images cannot be scaled up without looking bad. Since the pixel-density is different on mobile screens and many desktop screens, and mobile connectivity cannot be compared to an office high-end connection is perhaps more what is included in the concept of adaptive web design (AWD). A modern website will of course take care of these challenges and many believe that the concept of AWD is not even necessary (more on AWD later in the book).

Arguments for responsive web design

If you still need convincing about why RWD is something to consider, here are some common arguments of varying weight depending on the type of business you have on your website.

1. Google believes that RWD is the industry standard

“Responsive Design: serves the same HTML for one URL and uses CSS media queries to determine how the content is rendered on the client side. This removes the possible glitches of user-agent detection and frees users from redirects. This is Google’s recommended configuration.”
– Google, on their developer pages discussing various techniques for smartphones (2014)

Glossary – user-agent
Information the web browser relinquishes to each website during a visit. This tells the website which browser is being used, what version, on what type of device, the operating system and some other information. This is used on websites to know what type of equipment the user has, for example, to decide if the user has a touch screen, etc.

Besides recommending RWD, Google brought up two other examples; to serve different pages depending on the user-agent of a browser and the variant to send the visitor on to a separate mobile website. In their reasoning as to why you should choose RWD, they mention that it is the easiest solution among the alternatives. Since Google accounts for the majority of visitors you can get through search engines, their statement should not be regarded just as a suggestion on how to design your website (we can discus over a beer why they make this recommendation when you’re in the right conspiratorial mindset).

2. A single website to set up (for all types of devices)

Put all your energy into building one single good experience for all kinds of devices and screen sizes. There is no longer an option to build a mobile website since mobiles have very different sized screens. We would have the same type of challenge – except that you also have at least two different websites to administer.

Bear in mind that one person can use several kinds of devices to visit your website in a single day. Say that the person starts at work on a desktop computer to continue on a smartphone at the bus stop. If the website is not responsive, you will either have to start afresh on a mobile website and maybe find the corresponding page, but it may also happen that the usual website shows its worst side, which causes many to give up.

One of the CMS vendors, Epi, did a study in 2013 that found that 70 % never returned to a mobile website that was difficult to use, and it is probably at least the same for non-responsive websites visited on a mobile. Every other user asked was irritated by the fact that many websites are not designed for smartphones22.

3. Logical URL strategy

A responsive website has just one address. Also, a sub-page has only one address no matter what and can be used by a mobile user or someone who is using a different type of device. You probably have got e-mail from a friend, containing a link, clicked the link when on a desktop computer and landed on a mobile website – or vice versa got a desktop website on your mobile. It is of course not ideal and rarely optimal for what the publisher wants you to do during your visit.

With a responsive website, there is no need to be shuffling users back and forth between different versions of websites depending on what type of device they have.

4. The fewer sites you have, the easier to manage and maintain

Content management is easier and to follow up on how content is performing, you do not need to jump between different web stats accounts since the breakdown by type of device is only a simple segmentation in your analytics tool. All campaigns will be easier when you direct visitors to the same address. You get a better overview of how your landing pages are performing and can easily see on what type of device you can do a better job.

5. Responsive is more future proof

A well-executed responsive website works better on devices that are not common yet. At worst, you’ll have to make some minor changes later on. Say, for instance, that your visitors suddenly start using a browser on a gaming console on a TV. That scenario is well covered in RWD but in a non-responsive setting would mean yet another special website (re-using the arguments to have a separate mobile website).

Notes on responsive construction

The content itself does not automatically adapt to a small screen just because you made the website’s design more responsive on more kinds of screens. Among other things, it is a common comment that the main headers fill half the screen height, or that decorating pictures get in the way of actual content. In other words, you have a great opportunity to revise your content from a mobile user’s point of view. I would recommend the content genius Karen McGrane’s book Content Strategy for Mobile23 and try googling her lectures on the topic for a lot of good advice.

Some may certainly ask themselves whether to upgrade their existing website design or start from scratch. It depends on whether you believe that the content’s presentation and structure will function in a mobile scenario. If not, I think you should consider starting from scratch.

A large part of a responsive project is how to present pictures in the design and whether you even can afford to show pictures, which often take more space on a small screen when they compete with other content. In my first responsive project, we looked through the most visited web pages to see if we could do without images. Most often, the images were just decoration, which made the choice easy to instead prioritize the header, preamble and body text.

There are many creative solutions on how to try to resolve not sending unnecessarily heavy pictures or embellishing imagery to the small devices that do not really have space on their tiny screens. The variant we chose at Region Västra Götaland was that if the web editor does not expressly choose that the picture is also to be displayed for mobile visitors, it is replaced with a transparent pixel-sized image – which draws almost no bandwidth at all. The caveat with such decisions is that we cannot necessarily assume that a user on a small screen device is using a mobile connection; they may be using a hyper-fast Wi-Fi network. At the same time, I am one of those who use a mobile broadband at home on my desktop computer. Screen size simply does not automatically tell you what kind of connection is being used.

Figure 39: Photo 1024 pixels wide, 263 Kb file-size.
Figure 39: Photo 1024 pixels wide, 263 Kb file-size.
Figure 40: Same photo, resized to 320 pixel width. 33Kb file-size. Not as easy to identify the tall man, even for those of us who know who he is, Sweden's former foreign minister, Carl Bildt.
Figure 40: Same photo, resized to 320 pixel width. 33Kb file-size. Not as easy to identify the tall man, even for those of us who know who he is, Sweden’s former foreign minister, Carl Bildt.
Figure 41: Cropping the photo makes a big difference to recognize the content on a small device. 320 pixels wide and 34 Kb file-size.
Figure 41: Cropping the photo makes a big difference to recognize the content on a small device. 320 pixels wide and 34 Kb file-size.

The challenge of selecting images to use in a responsive scenario is to get just enough detail into any images portraying something or someone a visitor should recognize. A high-resolution screen the size of a tablet or bigger are in many cases able to display images a bit more zoomed-out, for example, 1024 pixel wide. At the same time, a small low-resolution screen will not always manage with exactly the same image scaled down in resolution, such as 320 pixels. Important details might disappear.

The thing to consider is that the image resolution, i.e. the granularity that provides clarity and detail in the image, in a mobile-optimized image is only about a third of a larger tablet. 320 pixels compared to 1024 pixels in standard-definition (SD – sometimes called the native resolution).

To use the same picture on a small, low-resolution screen that on a bigger screen is difficult when there are fewer pixels to give clarity to the smaller picture. You then need to crop the picture and remove some of the outline to favor a view of what the image is really portraying. If you show the original image on a small but high-resolution screen, you will send an image as heavy as for larger screens except that it appears smaller and super sharp – something that can be overreaching but definitely will affect download negatively.

Therefore, we need to choose images with great care, or replace them, so they fit the smaller-sized or less than optimal screens. At least it is worth checking how many users will suffer from a lazy photo editing job; there may not be a problem on your particular website. In other words, it is crucial to understanding and meaningfulness for pictures, that priority be given to the clarity of what they depict. Even more challenging is information graphics, full of text, charts and symbols. These challenges are what you look for when you go through the website to see if it has the prerequisites to be upgraded to RWD or whether it is best to start from scratch.

As you can see, responsive imaging is about level-headedness. The only advice I can give is to have healthy safety margins and see for yourself what your images will look like on different types of devices.

And, when writing, at least, the future standard is to specify multiple images of different sizes, where only the one matching the breakpoint in the style sheet is to be displayed. Say you have a media query for a breakpoint where all screens smaller than 512 pixels wide get a smaller, cropped, more obvious picture while all screens of 512 pixels or more, the larger, more sharp image is displayed. Then those with small screens with low-resolution images can get their image almost ten times as fast, not to mention that you may customize the version of an image suitable for a certain screen size, making it easier for the visitor to understand the content. Then you can make customized cropped versions for screen sizes specifically needing it.

“We’re not designing pages, we’re designing systems of components.”
– Stephen Hay, @stephenhay on Twitter

Web designer Brad Frost has described a system to think of websites as a collection of small pieces – Atomic Design24 – which is one of several ideas to move away from the heritage of classic desktop publishing, and its static page templates. I can personally recommend this, along with exercises to cut up prints of an existing website for insertion into one long column, to get non-designers to think more responsively about content they are already familiar with.

A website’s smallest design element is, according to Frost, the atom, which can be combined into molecules, which can become an organism for display in a page template, which with the navigation organism and other standard components form a web page. In this way, the search field is an atom, the search button another atom, and together they form a molecule of the website search interface. Together with the header’s other molecules, the website search forms an organism. Same with the page content (template), and the footer, all the parts constituting the web page. By dividing each web page’s ingredients down to atoms and piecing them together, you get a method that allows you not to get stuck with what should be removed to work on a mobile – instead you design your interfaces atom-up.

Speaking about mobiles. The most common argument I have heard against RWD is that it is not needed. What is common among these opponents of RWD is that they have more expensive editions of Android phones and a larger screen than the average person. These phones do not suffer quite as much from old-fashioned design. Then it becomes desirable for users be able to jump between the different breakpoints, if they want to find something that they know exactly where it is located on the desktop version of the website. Some mobile browsers have a function for this, where the user can choose to instead fetch the desktop version of a website. Another choice that will possibly emerge is to offer the choice of website version, maybe among other accessibility settings as text size, contrast and more. If you have an advanced or tech-savvy user base, they might expect to alter these settings.

Responsive typography

Since the column width on small screens is quite narrow, it gets risky with long compound words that might stand alone on a line, or in the worst case, cause unnecessary horizontal scrolling. In editorial and static text, you can prevent this by using a soft hyphen. Then a word is hyphenated if necessary. This soft hyphen is created using the code below:


It is &shy; which hyphenates if necessary. It is worth bearing in mind that this snippet of code needs to be sent unchanged to the visitor’s browser to work. That might force you to switch to code view in your WYSIWYG-editor, and it might not work in all text fields. Something you may have to talk to the developers about is to resolve problems with the length of the names of menus, maybe by using Javascript to replace each item with shorter versions of the names. For instance, if the page width is below a certain level, you replace text, ‘and’ becomes ‘&’, or whole words are replaced with slightly shorter ones so the text does not break the design.

Subjective taste alone does not determine design, such as column width. When the content type is text, there are typographic rules to adhere to. Ideally, you have somewhere between 45–75 characters per line for good readability, which affects how wide a column can be if the text should align more or less with the column’s right margin. The content demands a breakpoint if the lines are too long, or if you set a maximum width for text paragraphs solely for the sake of text readability. You can still allow for other elements, such as images on the page, to be wider than the text’s line length.

Web editors needs to use &shy; to hyphenate longer words, so narrow columns do not display only one or a few words per line since readability suffers. If you are not the only one to feed the website with content, it is surely a good idea to have a soft hyphen on the cheat sheet for the editorial tricks all web editors should know about.

RESS – Responsive Server Side

A logical sequel to responsive web design is RESS (Responsive Server Side). It differs from an orthodox RWD by advocating that it is ok for the web server to find out which equipment the visitor is using and send a customized version of the website. It is a bit like the old days when we sent different style sheets depending on whether the visitor was using Internet Explorer or Netscape as a browser. The difference is that today, it is much more complicated than just two different web browsers, nowadays some browsers even have APIs for cameras and light sensors.

A simple example of where RESS can differ from a regular responsive website is that if the web server discovers that the user’s connection is slow, the server will not send several megabytes of decorative pictures, instead just the bare minimum. If it seems to be a desktop version of a browser, you might choose to send heavier media content and prioritize a visual experience. Most first generation responsive websites send far too much data to mobile devices. That is the most common criticism. Broadly, with RESS, the same content is sent to all users; however, you customize the experience, unlike orthodox RWD, where it is justified.

Now you may wonder how the web server knows so much about its visitors’ equipment. There are several tricks, but the most basic one is to check the user-agent, i.e. information about the software you use to connect to the Web. This is what my user-agent looks like when using my computer:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56

Any web server I connect to can decipher my user-agent and see that I use a Macintosh operating system, version OS X 10.11, the Safari browser and the rendering engine WebKit controls the appearance of web pages. Check your own user-agent online25.

On an Iphone, a user-agent can look like this:
Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4

For a Google Nexus 5-phone, it may look as follows:
Mozilla / 5.0 (Linux; Android 4.4.2; Nexus 5 Build / KOT49H) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 32.0.1700.99 Mobile Safari / 537.36

As you probably noticed in the earlier examples, a user-agent is great for deciding what type of device the user uses. As on a computer or touch-based device, whether it is Windows, Linux or Mac, Android, Windows Phone, Apple iOS, etc. There are many conclusions that can be drawn only from the user-agent in order to send customized HTML code and content optimized for each platform. Among many things, you can use the user-agent to work out what type of optimized content you can send, such as the until now not so common image format WebP, which is about 39 % smaller in file-size compared to conventional JPG files for photographs.

Besides looking at the user-agent, a web server may need to know other factors that affect how you want to present your website, such as how fast a connection a user has. Exactly what a browser support constantly changes. The next time you have reason to do some development, check out what can be discovered by a web server.

Sorry, this section was a bit lengthy but there is so much to say about responsive web design as it is an emerging default for all web projects. Now we are going to talk about the successor, according to some, to responsive web design.

Adaptive web design

The idea behind adaptive web design (AWD) is to tailor each visitor’s experience, in detail. It is about using all opportunities available, by so-called progressive enhancement, which provides a good basic function to all visitors and lots of improvements depending on what features are supported by the visitor’s browser. One of the first adaptive design techniques often used was to allow modern browsers to take advantage of CSS3 early on, such as by applying rounded corners on boxes, while those with an old version of Internet Explorer got an uglier design.

I might as well mention directly that the discussion of this term’s necessity makes many of my friends at web agencies somewhat glassy-eyed, while pointing out that we do not need this concept since ‘all that is included, of course *sigh*, in a good responsive website’. I’m inclined to agree with them, but the reason I still like to bring up AWD in this book is to explain the variety of things available to customize. Depending on who you talk to, you risk missing that part of whatever a good responsive web might include at any time.

Figure 42: A website is asking if it can know my location.
Figure 42: A website is asking if it can know my location.

Think of AWD as a responsive website with the difference that with AWD, it is ok to give unique experiences depending on what context a visitor is in and to follow design convention applicable to each device-type, or even a particular device. An AWD website may send different HTML code for different kinds of devices, which is the biggest difference compared to RWD. When the user’s conditions are known, and worth adapting to, an optimized version is served. Many times you use Javascript frameworks, such as Modernizr, to get in black and white what each user’s device can handle. Modernizr checks how much support the user’s browser has for CSS3 and HTML5 capabilities.

Examples of conditions that can vary and be useful in the design of a website that utilize AWD:

  • Does the device have a camera? Can be useful if the user should be able to take a profile picture, or maybe shoot a picture of the object to sell online.
  • How is the device controlled? It may be important if there is a mouse pointer, if it is a touch interface etc. Otherwise, it can be difficult to interact with certain design elements. It may be neither a mouse nor touch screen but perhaps, the user’s entire body that is some sort of remote control instead.
  • Is it possible to pinpoint the user’s geographic location? This is crucial for location services but may also act as input for search criteria, such as geographical closeness to the user which can be used in a relevance model when the user does a search on the Internet.
  • What are the possibilities of sound, film and vectorized images? Among other things, it is good to know what formats the user’s device accepts so you can send the most suitable format that can be quickly transferred.
  • Does the browser support local databases? In some web applications, much work is carried out locally in the browser, and primarily what gives sluggish experience on the Web is sending the material back and forth to the server. A prerequisite for using the browser as a client software is in many cases that it can manage a local database.
  • WebSocket to allow real-time updates in the browser. Used to communicate between different users, and between the user and the web server in real-time games for instance. Messages such as those when you are informed that the other user has started typing a response, among others.
  • Web worker available to build applications? Web worker is a solution that uses Javascript the programming language of the Web. The user’s browser can now host applications, which are used in Single Page Applications (SPA, more on this design principle later in the book).
  • Can the device make a phone call? Used to convert phone numbers into links initiating a phone call. If not present, you might link to a function where the user can ask to be called instead.
  • Resolution of the screen? There are so-called high-DPI screens (sometimes called retina because of Apple users), on which normal resolution images are perceived as blurry. Especially true for text in images and even logos.
  • What is the speed of the Internet connection? As an example, if video is to be streamed, it requires a certain bandwidth to be worthwhile. Otherwise, you may offer a discreet suggestion to download. When on an acceptable to good bandwidth, the server can automatically select a suitable bandwidth use for it not to be buffering interruptions in the playback.

AWD does not necessarily mean that the content, such as texts, changes depending on the visitor’s context, such as their geographic location, for example. It is more of an overall website design level. Granular control over what content shows up belongs more to the concept of personalization, however, with the exception that an AWD web needs to prioritize content suitable to be displayed on smaller screens or odd devices.

However, we can, and perhaps should make sure, at least as a community actor, that an incredibly condensed version is offered to those with clearly substandard Internet connections. If transfer is particularly slow, the visitor gets a lite website with just the essentials. There, the user themselves, like on a mobile website, can choose to go to the full website if they have the patience or switch to a better connection. It does not send any images or materials heavier than text and basic design to bring just the most essential content. This solution might serve as some kind of emergency version if the server or the network becomes overloaded.

Example 1: Fast Internet access
A fast 3G connection at nearly 16 Mbit / second downstream and 0.048 seconds response time.

Example 2: Slow speed
Worse 3G connection at 0,035 Mbit / second and 1.2 seconds in response time.

You might be thinking that it is not so bad, but then you have probably never been on the outskirts of the 3G network and experienced a visit on a responsive website. For those who find themselves in the countryside, this is the normal situation. To exemplify the two situations, I measured my connection speed. When downtown in Gothenburg, I had 16 Mbit / second downstream and 3 Mbit / second upstream with a delay of 0.048 seconds. In a cabin, out in the woods in Fengersfors, there was however a bit more modest 0.035 Mbit / second downstream and 0.4 Mbit / second upstream, with a delay of a full 1.2 seconds!

If I try to put these numbers in perspective, in my cabin it was slower than surfing with the dialup modems of the 90’s, those 56 Kbit / second modems, with over one second of lag for each file before it started sending. To make matters worse, today’s websites are immensely more burdened with large images, Javascript and style sheets, each of these files adding a second to the wait time even before starting the transfer.

Let us calculate a little how this might affect a visitor on a little too obese responsive website at 5 MB divided into 30 different files – a weight many Swedish municipalities deemed suitable with their fine responsive homepages. With the fast connection example from earlier, such a website takes about 1.4 seconds of delay plus 3.2 seconds to download. For an abnormally heavy webpage, it is quite ok that it is loaded in under 5 seconds. The same material sent through the slow connection example though instead takes 35.8 seconds of delay and 143 seconds to download. That is almost three minutes!

Where AWD shines is that it is more obvious that you should not send files to the visitor they have no benefit in receiving. Many responsive websites often send photos in a larger format than the visitor’s screen can display, not to mention that images are sent and not even presented to the visitor. There is of course no point in being so orthodox to responsive web design that you do not apply this kind of optimization, and personally, I think optimization is what caused the discussion on AWD vs. RWD in the first place. AWD supporters claim that their version is better optimized and loads much faster – while RWD supporters believe that AWD people build multiple sites in one.

The question is how many devices the website should be optimized for. The five most popular? Which devices are popular can actually change quite quickly. The number of unique kinds of devices your visitors might use is amazing. At our mobile moment, in 2013, there were 355 different kinds of mobile devices identified on the relatively well-visited website, which points to the need to think responsive even when building AWD since screen sizes vary greatly and you cannot provide unique customizations for all of them. Begin with your web statistics, if you are selling something on the website, you can look at what devices are less profitable than average – if there are enough of them, there may be reason to find a solution. For non-commercial websites, you have, I hope, other metrics indicating whether a user’s visit was worthwhile for both of you.

Figure 43: Of the mobile user’s at during 2015, 66 % use an Iphone or Ipad, 33 % Android, and the remaining percent Blackberry, Windows Phone, Nokia, etc.
Figure 43: Of the mobile user’s at during 2015, 66 % use an Iphone or Ipad, 33 % Android, and the remaining percent Blackberry, Windows Phone, Nokia, etc.

The design of most AWD websites is like any modern website that follows RWD, but unlike RWD, the experience can differ vastly between different types of devices.

Personally, I think AWD is most interesting as a counterforce to the urge so many seem to have to build simple information-apps for mobile phones, instead of taking care of their existing website. With a good dose of Javascript and a little redesign, any website can look and behave like a mobile app; then it is just a question of putting a shortcut on the home-screen for the mobile. It is also on mobiles that the interesting elements of AWD pop up since you have other design conventions. The design should feel more like a mobile app in the navigation and esthetics of design elements.

HTML5 has an API for battery status on mobile devices; an AWD website should obviously use this when it makes sense to, among other things, to reduce the amount of network requests to conserve the battery’s remaining capacity.

Figure 44: Gray bottom and black text is perfect during the day.
Figure 44: Gray bottom and black text is perfect during the day.
Figure 45: A dark theme is great at night or in dark surroundings.
Figure 45: A dark theme is great at night or in dark surroundings.
Ever felt that the lighting on your mobile is too bright at night? Most probably! The Web standard organization W3C has developed a recommendation called Ambient Light Events, which allows us to take advantage of the light-sensor that is present in some computers and almost all mobiles. What to make of this information when designing a website is up to us, but personally, I would probably make a design for daytime and one for nighttime. Many of today’s applications have this feature but you have to toggle manually.

How do you know that your website performs as well as possible? By continually evaluating data on users’ behavior of course. This will be our next topic.

Design with data – a data first-approach

When you choose to let data guide the design of a service, it is a way of working with what evidently actually works, or does not work, and what could perform better. It is a way to gain experience in the usage of a service, for the next update to be even more in line with what users expect. A rather unpretentious approach to design.

If you are going to use data to guide design, you will first need to specify what the website’s purpose is, what it should be able to help achieve. What role it should play in the bigger picture. In some cases, you might not have a clue why the website exists, then a look at the organization’s business plan is a good idea – there overall goals should be found, goals to break down into measurable goals for how the website can bring value for the organization. If it is more of an information-heavy website, the definition of exactly what well-performing metrics are for the website might be found in a communication plan or project directive. The goals for the website to strive for should be documented and reconciled with all concerned.

Being able to break down an entire website into multiple parts that are graded according to whether they are valuable is probably not an approach everyone is used to. If you do not feel that you can see or explain what benefit the website contributes to the bigger picture, then this approach is a great way to finding out and discovering what can be improved.

To develop metrics, often-called KPI’s (Key Performance Indicators), is a tough job and slightly off topic for this book but it is worth mentioning that you will be working with both quantitative and qualitative means of measurement.

The difference between them is that:

  • Quantitative metrics depend on automatically collected data, such as signals indicating a behavior in actual use of a website. These figures answer questions such as who, what, when and where about the use/user. This information, among other things, is to be found in your web analytics tool.
  • Qualitative metrics are data based on interviews, surveys, and other things that reflect people’s own subjective beliefs or actions. Data refers to these people’s answers to questions as to why or how about their reasoning or behavior – anecdotes in other words – but can also be based on observation of users when given a task to solve.

An example of quantitative measurement is a figure for the number of visitors from Europe during the month of January. A qualitative measurement may be that most visitors, in the mobile category in a web survey, indicated that the service works much better generally on mobiles since a redesign. Quantitative values suggest the extent and qualitative values gives perspective.

Get started with design with data

If you are starting completely from scratch with a service, you perhaps do not have any own data to work with. But if you are creating a digital equivalent of an offline business, there are certainly some conclusions to draw from offline to make qualified assumptions for the initial online service design. Whether you have an existing business or not, digital or offline, it is a good idea to do some research. Check the digital counterparts if there are any, and especially potential competitors. Being guided by the data means that you are prepared for continuous change, which means that you need to be careful with your data collection. Quantitative data is often useless if we compile it to a too high abstraction level, but in an overly narrow segmentation, statistical base becomes so small that it is hazardous to draw any meaningful conclusions.

As you have probably realized by now, it is a difficult balancing act to choose the questions your data can answer. Look critically at your data. I hope that you will not have any unpleasant surprises later on (when someone else reviews your data).

Your metrics should be specific and isolated enough to answer a question about use. The number of visitors to a website is interesting and all, but to make a website better, it is more important to know how many people abandon their shopping cart before payment. Instead of being satisfied that the website has 10 % more visitors than last month, the person working guided by data will look at more meaningful quantitative data (When is the shopping cart abandoned? At checkout, perhaps?) Moreover, use qualitative data, such as asking visitors about their experience of the buying process, to optimize even further.

By now, you have probably figured out that the website needs to have clearly stated goals, and preferably documented, for many of the individual sub-pages on the website – frequently there are several goals per page. These goals form the long list that almost every website modification should align with and strive to improve.

Some pages will have goals that conflict with the site’s primary goals, or what many consider a criterion of communication with the visitor. For example, it is common to want a low bounce rate (when a user visits only one page and then leaves), therefore, that a sub-page does not result in visitors leaving the website. But there are pages whose content refers to other sites. In such an instance, a high bounce rate is a measure that visitors understand the purpose of the page, accept it and use the link to the other website. This is an example where the overall goal to keep visitors on the website is opposed by some sub-pages. Reports of how the website is performing must be adapted, so an increased proportion of visitors to certain sub-pages will not make it look as if the website is not performing well.

What you know about your visitors

To know what is worth adjusting on a website requires a certain knowledge of who your visitors are. The different types of visitors are your segments in this type of design. A segment is a recurring visitor; another is a logged-in customers who has placed a certain kind of product in their shopping cart. What you need to think about, and collect data on, is what is needed to make each segment to convert – then change what you need to on the website. A conversion can be to recruit a new customer to place an order, but it can also be a less grandiose goal such as getting a visitor to click on a link to the organization’s profile on Instagram. Which converting activities a visitor can do of course depends on what part of the website the visitor is on. That each page should be contributing to converting visitors will certainly be shocking to some web editors, especially in the public sector (who historically have been a bit lax on what needs their websites should aim to fulfill). Nevertheless, where an online shop is trying to make money, the public sector is more about getting visitors to know their rights, use digital services or click through to other relevant sites.

It is crucial to know why a page exists, what it is supposed to bring to the bigger picture and how it meets the overall objectives of the website. If you cannot answer the question ‘why’, the page should probably be deleted.

Optimization needs to be done within a smaller segment of users and the greatest benefit is that if you can find out which ones have the most difficulty converting – i.e. what type of visitors you cannot manage to convince to do a desirable action on the website. It may concern segments such as ‘those with the greatest problem to get through the checkout process with their shopping cart’ but also may involve converting ‘visitors entering on the landing page for a trip to Greece’. To find these segments is something that requires business knowledge and it is quite difficult to hire consultants to remedy this. The answer to these challenges is not always to redesign the website. It could very well be to reach out with a newly created landing page for destinations in Greece, or to make it easier to see what users are supposed to do on a certain type of page.

In some cases, we know quite a lot about visitors, sometimes because they are logged-in and have provided useful information about themselves, such as the sector in which they work. Sometimes you do not know so much and you have to lump them together according to how they ended up on the website. Did the visitor come through a campaign link, a newsletter or spontaneously via googling? Yes, it can make all the difference in whether your website is capable of converting the visitor into a customer, a fan or whatever you are looking for with the website. It is in these details you are looking for new segments to improve how your website delivers based on the quantitative data on how users behave. Then if you find a large segment of visitors who do not do what you want them to on the website, you have a great untapped potential to work with. If you have information about logged-in users belonging to the public or private sector, or other grouping that are underperforming, just start by thinking about what could be better. All the data about your visitors is good data when you like a detective is looking for the underachieving group you should try improving first.

Something you have probably already seen, but possibly not reflected on, are the checkout deals available in many web shops just before you finally pay. This is the digital counterpart to when you find candy, batteries, magazines, and other well-chosen items close to the checkout where you queue up to pay in a physical store. Of course, these checkout deals should not to be static and the same for all customers on an online shop. What is offered first should be something that complements the purchase and offers a good profit margin. The risk is that you lose customers through the introduction of this intermediate step at the checkout.

How do you know that the step at the checkout is worth the risk of your customers abandoning their shopping cart? Alternatively, what extra products should you offer before the purchase is completed? By testing various other designs! You can use the data to see if it is worth having an extra step before checkout for your customers.

Continuous A / B testing

By continuously working with so-called A / B tests, you test your hypotheses for which design is most successful to convert a visitor to a customer. An A / B test is a competition where you prepare two different design versions of something you want to measure and see which design gives the best effect on real users. It may be small details, such as which text works best for the button to add an item to the shopping cart. How visitors react to a landing page, to measure how visitors react to major design decisions – such as the number of columns with content. Or why not find out which extra accessories customers choose for each product.

Example of A / B test to perform on a design:

  • Version A – Current page template with two columns for the page’s unique content.
  • Version B – Alternative page template with only one column to give more area to display photos, maps, videos etc.
Figure 46: Version A with two columns of content.
Figure 46: Version A with two columns of content.
Figure 47: Version B with a single column, an attempt to make the map better.
Figure 47: Version B with a single column, an attempt to make the map better.

These versions are randomly distributed to visitors during a test period, and it is important that you split up the visitors instead of switching versions every other day. Half will receive version A and the other half version B. It may be that the test is designed to run on a particular segment, a subset of visitors, to be able to isolate the hypothesis. For example, we may want to test different design ideas only on new visitors and see if you can get them to convert to a greater extent. It is not a good idea to test major design changes on returning visitors as they already have an idea of how the website should work, if you do this, try to avoid surprising the visitors.

To test matters of design you may want to evaluate how new design elements are received by users, or how many columns of information work best for those with small screens. Or whatever you want. Once the testing phase is over a winner is selected, probably automatically based on the success criteria you set up in advance, and will be the version that continues to be used in the future until a new contender comes forth. Sometimes, the test will not be conclusive as there is no significant difference between the versions, but regard that as a valuable lesson for future tests.

Figure 48: From, notice the "More on this". The placement of these suggestions in articles is probably not coincidental on news websites.
Figure 48: From, notice the “More on this”. The placement of these suggestions in articles is probably not coincidental on news websites.

Be careful and avoid designing your goals in a way that conflicts with your visitors’ interests. For example, it is not a great idea to reduce the emphasis of links to your partners’ websites to achieve your website’s overall goal to keep visitors on your own website. Statistics are not an end goal in themselves.

Examples of A / B tests for monitoring the website, and other communications

How your A / B tests should be designed you know best yourself, but I want to introduce some examples of tests that may be worth looking at.

  • Design of buttons and links, and their text, color, size and placement. In addition to obvious usability problems such as making sure that something is easy enough to discover, it could also be that the color and distance to other design elements, etc. play a major role. How to style text can make all the difference in the world, for example; it depends on your visitors’ interest in technology if a link should say ‘Subscribe’ or ‘RSS Feed’ as link text – this needs to be tested and measured.
  • Design two alternative forms for sign-up. A person who backs away or encounters usability problems with the form is a lost customer.
  • Evaluate photo selection on landing pages. Which type of imagery works best to inspire the visitor to add something to the shopping cart?
  • Length, and wordings, of texts. It is worth testing how product texts and headers are composed. Do texts need to be shortened for mobile visitors? Try.
  • See how customers react to being reminded by e-mail about products in abandoned shopping carts. Can be a series of tests to figure out which customers react positively to a reminder but it may need to be tested if it works to varying degrees depending on the type of products.
  • Send two different newsletters, and measure which one has the lower percentage of unsubscriptions. Just as data about which parts of a website are popular, you can measure what content is appreciated when sent to people. It is not necessarily the same content they are browsing on the website that is suitable when sent to their mailbox.
  • Test different offers when mailing. To send offers very few are interested in is a waste of everyone’s valuable time and attention. If you have not yet tested enough how to make the most of each mailing, test two different versions of mailings and then compare their efficacy against the business goals.
  • Placement of a secondary call-to-action. Since many important pages can have multiple goals, it is a good idea to test the optimal placement of call-to-actions other than the primary ones. It is probably not a coincidence that many of the established newspaper websites have tips on related news embedded into its news text. I guess that probably the exact position in the text is not haphazard, either. Rather it has been evaluated to see how far into the text such a link has the most effect to keep the user on the website. It all comes down to generating those page views you can sell to advertisers.

Someone who is well versed in testing and optimization when selling online is the Internet giant Late 2013, they were granted a patent on sending goods even before the customer ordered anything. To summarize Amazon solution in the patent’s abstract:

“A method and system for anticipatory shipping are disclosed. According to one embodiment, a method may include packaging one or more items as a package for eventual shipment to a delivery address, selection of a destination geographical area to which to ship the package, shipping the package to the destination geographical area without completely specifying the delivery address at the time of shipment, and while the package is in transit, completely specifying the delivery address for the package.”
– US Patent and Trademark Office’s registry26

How would Amazon be able to do this? Perhaps by keeping a close eye on visitors’ behavior and relating it to the sales. They track your behavior through massive data collection, for example, the likelihood that you will be ordering granola muesli increases if people in your geographical vicinity suddenly start buying it, or those you follow on Twitter write a lot about it. However, the trend does not need to follow a geographical or social graph; it can consort with other factors. A rather peculiar example is the American store Target when they, through a teenager’s buying patterns, realized that she probably was pregnant and offered products based on it. The teen’s father was dissatisfied with the store suggesting his daughter would be having a child so young, while his daughter was in fact pregnant27.

Mobile first

To build a website for mobile users is not just about making it usable for those with small touch screens. Mobile first is the title of the book on the subject by Luke Wroblewski which puts the mobile user’s needs first, both in terms of advantages and disadvantages.

When going mobile first, you do not expect the user to have a stable Internet connection at a high speed. Nor that the environment around the user is ergonomic. Rather, you are inclined to think the user might be on a bumpy bus ride in the wilderness with a blinding sun, or soon to enter a tunnel and lose their connection to the Internet.

Studies show that those who surf on mobiles are more impatient than others are, probably because they learned that it is not worth the wait. This makes for extra prioritization of the speed and usability. Mobile visitors also expect a different design convention compared to the desktop web, and how the interaction is managed. For example, it is natural to swipe images sideways if you are primarily a mobile user and the many services we are used to in apps adapt content to the person’s geographical location. There are simply different expectations from users, expectations we need to consider.

A not entirely implausible consequence of making your website mobile first is that returning desktop users not encounter unavoidable confusion on where content has gone, but also that on a desktop computer, it is to such an extent simplified that the user can be inclined to believe that an error occurred. At the same time, we cannot wait until most visitors use a mobile phone. Therefore, we need to design something simple, which without compromising mobility can scale up to meet the expectations of those on a desktop computer.

Mobile first vs. responsive web

The difference between a responsive website and a mobile first-website is what is considered normal, what equipment we are optimizing for. Most responsive projects I have heard of assumed that the one website would be able to adapt to different sized screens to display the content. Responsive websites tend to be about two or three editions for a small, a medium and a larger screen. Since the big screen is easy to default to, the ordinary way of thinking is that the mobile screen size is an exception to a desktop screen which then is scaled down to a mobile experience. In this classical way of thinking of web design, one does not necessarily consider the mobile as a constant to relate to.

Figure 49: Adlibris was the first ‘mobile first’ website I encountered from my desktop, it looked a bit, sparse, compared to its predecessor. Only two links in my account, one for previous orders and one for my digital library of ordered books.
Figure 49: Adlibris was the first ‘mobile first’ website I encountered from my desktop, it looked a bit, sparse, compared to its predecessor. Only two links in my account, one for previous orders and one for my digital library of ordered books.

In many cases, a website following mobile first even becomes better on desktop computers compared to earlier websites since we have to prioritize what to put on the limited space available. Often the appearance is more consistent between different types of devices compared to responsive websites, which makes it easier for all of us who use several types of devices regularly.

Figure 50: Website clearly making the most of the available space.
Figure 50: Website clearly making the most of the available space.
Figure 51: Enhancing some details of the design for bigger screens.
Figure 51: Enhancing some details of the design for bigger screens.

With respect to size, mobile first is designed for the mobile screen, and then if you have the opportunity and know what to add on a larger screen, it is added. Similar to RWD but starting with the small screen and working your way upwards. Strictly speaking, for mobile first, responsive web design is not really a competitor; a good mobile first-website needs to be responsive to function as intended for the plethora of mobile devices.

The mobile opportunity

Many things favor a mobile device when using the web. The most important point is of course that a mobile device is in fact mobile; that you can continue with something that you were doing, once you got on the bus, paid the fare and sat down. All mobile phones have a lot of sensors and equipment we would not normally find in desktop computers. One of the most used features is to locate the mobile phone geographically, which is fantastically useful for geolocalization services on a website.

Almost all mobile phones have sensors for the device’s orientation and an accelerometer that allows the mobile to be aware of its surroundings. It remains to be seen whether a website makes any sense of this, but off hand, I can imagine that if the accelerometer indicates much motion, there is a need for simplified forms, increased text size and other usability adjustments.

It is easy to forget nowadays that one of the major innovations of mobile phones is that they have touch screens. This allows for a much more intuitive interaction with your fingers instead of the user accustomizing themselves with various external pointing devices. What touch screens can be used at the end of the day remains to be seen. So far it has mainly been about making the interaction between users and services more natural, including examples such as the user defining an area on a map to look for a diner at lunchtime.

Imagination is what limits in our use of cameras, gyroscopes, microphones, light-sensors, vicinity sensors and all other kinds of data.

Mobile restrictions

The fast 4G network (LTE), compared to 3G, covered about half of Sweden’s sparsely populated areas in 2014 while the faster version of 30 Mbit / second only covered 2 %. Vodafone Germany plans to cover 90 % of German households by the second half of 2016.
Source: PTS (The telecommunication authority in Sweden) and ITU28

The limitations of mobiles can be summarized as follows:

  • The screen is often small. Compared to the earlier idea of a normal screen, the first handsets only have one-fifth as many pixels. Now there are devices with high-resolution screens, but they are still very rare compared to a desktop computer on many markets.
  • Mobile – mobile in the sense that the user has it in their hand, watching out for traffic, and continues to use it even when going into a bomb shelter underground, where it loses reception with the cellular network.
  • Context – think about the ergonomics during the use of a mobile, as light-conditions affect the contrast needed to read text and more. We cannot expect the user’s undivided attention, even for a short while at home in their living room since mobiles are usually used with other things demanding attention.
  • Often with a sub-optimal connection – if a fast Wi-Fi network or 4G is not present, a mobile device has a hard time dealing with many or large files for download.
  • Monthly data plan – it is very common that users have a monthly limit for how much traffic they may use. This means that users needs to limit their traffic and are not very willing to receive unnecessarily large content.

The concept offline first is something that we probably should include in the concept of mobile first. The idea is that the user should be able to disconnect from the cellular network and, as far as possible, continue using the website. Mobile users are accustomed to apps functioning without connectivity and probably using local data. In these cases, users are not interested whether, from a technical point of view, they started a native mobile app or clicked a bookmark on the phone’s home-screen – it is simply supposed to work. In a mobile or offline scenario, we should not consider a dropped connection as an error and tell the user that they are offline, instead, they are, as far as it is economically feasible, to be assured that the service works, even though there are periods without reception.

There are many occasions when you have a shaky connection to the Internet. Imagine traveling by train or subway, or a car ride in a hilly countryside and all other situations that will not magically work out with respect to connection across the globe in the near future. When you have a connection, it is often of a dubious quality, which means that it may take several minutes to download a less than optimized website. This we will go through in depth in the part about web performance later on.

The mobile moment – when mobile users are in the majority

In 2013, 80 % of Japanese people use the mobile web. While 25 % of mobile web browsing Americans almost only used a mobile device. Only in exceptional cases, they used something else, such as a desktop computer.
Source: Mobiforge29

Exactly when the mobile moment occurs, when most of your visitors use a mobile, differs depending on which users you have. In some cases, this has already happened and for a few, perhaps, it will never occur.

In 2014, Facebook released statistics showing that about three quarters of their users visit the service via their mobile phone. More amazing is that almost one quarter use Facebook only from a mobile. For those of us who work in offices, it can be easy to think that people still have a “real” computer they use for several hours each day, including surfing the Web for both job-related things and leisure. Even though many probably are in that situation, you should not assume that it applies to most users you want to communicate with.

When is your mobile moment and are you ready for it? If it tends to take a few years to improve your website’s design, maybe it is time to start with mobile first today.

SPA – Single Page Application

The idea with SPA is to give feedback at once from a website instead of the usual behavior to request a new page and then wait for it to be loaded. There is ongoing communication, out of sight of the user, between the browser and the web server to load the content constituting the web application. SPA is common on websites with content that is continuously updated, for example, where there is a flow of new posts to be loaded, without having to reload the page to see them. Frequently, these websites are designed to resemble applications on a desktop computer rather than a regular website.

Another common SPA feature is that the entire website is downloaded locally on the device, which makes for extreme performance while becoming independent of a connection to the Internet. The challenge is that these applications often occasionally need to be updated or synced with a central server. There is good support for these technologies thanks to HTML5 and specifically Web Storage.

The concept of SPA is probably best known in tech circles, but many recent great mobile sites, many of which display an app-like behavior, exemplify what this design strategy is all about.

SPA is heavily dependent of Javascript frameworks and modern features in your browser. A technique you probably heard about is AJAX, which manages the exchange of data between the server and browser. This is based on the use of APIs, which makes it more of an architectural concern because the website is tantamount to an app – a window to the API. There are two variations on how the information is sent to the browser. Either it is sent as raw data, usually in the format JSON from the API, or it is pre-formatted HTML codes to update the content on a particular part of the page. For example, presenting new e-mails in the inbox would only contain structured raw data, and then some Javascript code in the browser adds the design, bold, wrap, etc. Otherwise, new e-mail is sent from the server to the browser as HTML code, making it ready to be presented instantly in the browser, pushed into the top of the list of e-mails.

If you thought of also having a mobile app, or external users of the API, there is reason to choose to have the API send raw data since HTML controls in detail how the appearance should be.

Many websites have components similar to what constitutes a SPA website. The most common example is probably the ones that offer messaging between visitors who find themselves on the same website, like the message window you have on Facebook to talk in real-time with other users. Another common SPA-like feature is the listings of content, which is automatically updated with new content, like a stream of information. To give content updates and direct communication between users on a website, the web standard WebRTC (Web Real Time Communication), and WebSocket among others is used to deliver features that were previously impossible on the Web. Having a long-lived connection for real-time communication directly between clients is a bit of a novelty on the Web.

Tech-savvy people and some web developers around you will take great interest if you mention SPA, but there is something essentially non-technical to remember, namely that SPA may be excellent for small web projects that emphasize speed of use and perceived smoothness. SPA is also good if you are not quite sure if you will build a mobile app later, as a lot of the investment already made in the API will help.

Figure 52: Many early SPA-websites mimicked the design conventions of Iphone apps, when it still was skeuomorphic.
Figure 52: Many early SPA-websites mimicked the design conventions of Iphone apps, when it still was skeuomorphic.

Design of SPA websites

Although SPA is primarily a question of technical architecture, there are some common characteristics when it comes to appearance. The early app-like websites often built a mobile website since the web code could also be compiled into a native mobile app. Therefore, some looked like the first generation Iphone interface.

As the Iphone’s market dominance diminished, the design language has become more neutral, and a common denominator for SPA sites is that they are very similar to apps in appearance and function. They often ask you to add them to your home-screen on a mobile. If you do that, the difference between a native app and a website is not necessarily noticeable.

In addition to the app-similarity, many SPA sites also focus on giving an overview of many things, such as with so-called dashboards. This application behavior means that users really only have one view of the website, rather than the plethora of unique templates for different types of content they are used to, which can be both a good and a bad thing.

Recently, many variations on the SPA theme has evolved where you have one long web page and links to different sections using internal links, often with eternal scrollbars where new content is loaded when approaching the bottom of the page. Plenty of websites have a single page that is SPA, among a group of ordinary pages, the application itself is SPA and the rest is an ordinary website.

Challenges of SPA

The fact that there is so much Javascript and dynamics is not sensible when it comes to search engine optimization; you cannot take Google ranking for granted when going SPA. A common behavior on an SPA website is that there is only one single address regardless of where you are as a user within the application. So there are no different addresses to index into a search engine, but really just a start page – this makes the website’s content largely invisible to search engines and their users. There are ways to solve this, which is often necessary to get the web app to work without Javascript enabled in the user’s browser.

Figure 53: Hultafors’ website behaves as an app if used on a mobile.
Figure 53: Hultafors’ website behaves as an app if used on a mobile.

The same problem with addressing also affects users who think that it is possible to copy everything in the address bar and send to anyone, for that person to see the same thing as them.

Something to keep in mind is to abide to the navigational conventions visitors are accustomed to. For example, it is, unfortunately, common that the expected behavior of the browser’s back-button on SPA websites does not occur. Sometimes you are logged out but it may well be that nothing happens at all.

If you strive to make your SPA-site functional offline, it requires some planning to have everything downloaded in time. There is probably a priority order of what content you want offline if you cannot choose to have it all. Probably much will be downloaded and never be used; therefore, you could consider having only text locally on the device and download heavier material, such as pictures, later on if the conditions are right (check out the design pattern called lazy loading30). When on a slow mobile connection, one needs to adjust what is downloaded, and on a public website keep in mind that some visitors may have a monthly data plan, a quota to be considerate of.

SPA is all about offering the functionality that the user’s device is capable of, and it has some certain challenges regarding fault-tolerance, a subject we soon will talk about.

Web standards, and usability

Glossary – usability
A measure of how easy it is to do specific tasks with a product, a website or other features. In the web context, how easy it is to understand how to interact with a website, a measure of whether it is intuitive or not.

Glossary – accessibility
How well it works for people with some form of disability, such as visual impairment, motor problems, learning disabilities and similar.

Glossary – web standard
To follow established, open and inclusive standards and practices when designing a website.

To round off the topic about web design, I think we need to go through what a good website is and if the website works as it is supposed to. What is published has to be useful and follow established standards as far as possible.

Web standard is based on the underlying principle that all users, regardless of their physical or technical capabilities, are able to use a website. The original idea was after all an open and inclusive Web, and the use of common standards supports this idea. Opposites of web standards include commercial or proprietary formats such as Adobe Flash or Microsoft Silverlight. Instead, we should use open formats such as HTML5 and others developed as recommendations by W3C and other credible groups without any obvious self-interest. We should choose standards that set requirements as low as possible.

Usability is not only about ease of use but also about bringing something meaningful, having an objective in common with the user. A first level to aim for regarding usability is to make sure that what is built works on the devices your visitors use, designing everything fault-tolerant since there is a vast variation among visitors’ equipment, but still sticking to web standards.

Progressive enhancement and graceful degradation

Glossary – progressive enhancement (PE)
To assume that the visitor does not have the latest technology, or most recent browser, or all possible plugins, but instead offer a basic version that is good enough for anyone.

Glossary – graceful degradation (GD)
Design of system to fail gracefully. When errors occur, or needs are not met, the system will not crash if avoidable. Stylish error handling where it is planned for, in advance, that errors may occur.

Progressive enhancement (PE) is a design approach that above all prioritizes accessibility, the code validates established and widely used standards rather than aiming for an awesome or experimental experience. It is about offering a stable and reliable website without extravagances we just as well could have done without.

However, the concept around PE also includes the idea that once you have delivered the basic needs, it is of course acceptable to add features that will only benefit the few who meet the technical requirements. Under controlled circumstances. In other words, you do not create a page where those who do not have a certain obscure plugin are told to download it, rather it should be invisible what you are missing out on. A typical example is the transition period when not all browsers had full support of CSS version 3, which ensured that the design worked well without CSS3 but those who had such support in their browser, could see small improvements such as round corners, for example. What is important here is that no design choices cause other users to have a less pleasurable experience.

Figure 54: Javascript and CSS makes a form more usable for those with modern browsers.
Figure 54: Javascript and CSS makes a form more usable for those with modern browsers.

If you read the section about adaptive web design you have already seen the idea behind PE, namely to add something to the user’s experience if the device or context supports it. PE is usually about web design in terms of graphical appearance, but there is no reason to neglect visitors’ connection speed – if a fast connection is used, we can just as easily stream video in Ultra HD format for optimal quality. In other words, we can argue that mobile first is PE because it starts out with a small screen and adds content if there is more space available.

Graceful degradation (GD) is in some regards PE’s opposite since GD means designing for the most modern and optimal technical equipment a user may have in the form of browser support for new technologies. To be usable in older equipment, you need to build in lots of fault-tolerance.

A way to tackle the problem that some browsers (yes, Internet Explorer has historically been the biggest scapegoat) do not support the latest web standards is to use a so-called polyfill. Polyfills are solutions for features you have good reason to believe that most browsers will support in future releases, but for it to work in older versions, the polyfill has supporting code for fallback. An example of this is that support for SVG images (Scalable Vector Graphics) is very diverse, so instead of having yourself to develop special code for each browser and version, you use a polyfill. In this case, the Javascript framework Modernizr can help. Say that the user, in the case of an SVG image, is using Internet Explorer 8, then the polyfill will see if the user at least has Adobe Flash installed, and if not it gives up since IE8 by itself is not capable of displaying SVG and Flash did not work as a fallback. Instead of giving up instantly when needs are not met, it tries in a structured way to resolve the issues with older equipment.

Whether we choose GD or PE is revealing as to how we look at our websites and the requirements placed upon the users. Need I mention that PE is a further development of GD? You have probably read between the lines by now that I prefer PE 🙂

Usability vs. accessibility

Two concepts which in many ways can be seen as the same thing, namely usability and accessibility, is something that often seems to create headaches for people.

Figure 55: I’m guessing that the person who wrote that caption is able to take the stairs.
Figure 55: I’m guessing that the person who wrote that caption is able to take the stairs.

The most popular way to distinguish between them is that usability is about the website’s ergonomics for a common user. Ergonomic so they are able, for example, to get through a payment process in an online shop. Accessibility puts more focus on allowing as many people as possible to use a website, including those with temporary or permanent disabilities.

When speaking of disabilities, the blind and their needs are most often used as an example. It is deceivingly simplistic since accessibility is something most of the population can benefit from. We all benefit when we are tired, in bright sunshine with a mobile, are forced to use a gaming mouse with too-high sensitivity or receive the text version of video clips when we have forgotten our earphones and are in a quiet environment.

There are of course helpful guides on how to develop a website in an accessible way. Two common standards to follow are; WAI – Web Accessibility Initiative31, and WCAG – Web Content Accessibility Guidelines32. WCAG is actually a subset of WAI and goes specifically into the exploration of web content on a website. WCAG is based upon four principles, namely that a website should be:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

Whether or not you are aware that your audience consists of people with special needs, it is important to have a good basic level of accessibility and usability. It is encouraged by search engines, and I guess you want traffic on your website? Although some but not at all care about the needs of the blind when designing a website, it is worth bearing in mind that Google also cannot see, and for the moment, Google cannot hear. If you do not care about getting visitors through search engines or always having all the employees on top when accessing the intranet, just carry on ignoring it.

Accessibility is about taking into account people’s varying needs. People with the widest possible variety of characteristics and abilities, including those with various disabilities, should be able to use a fully accessible website. Among common accessibility challenges are, for example, that the text actually is real text for a person with a screen reader and not an image, as well as that headers in the code are marked up as headers instead of bold and enlarged text, and that the page has a page title. Simple stuff, most of it.

Usability has more to do with efficiency and the perceived experience. A website may be perfectly accessible, but still not very usable, if, for example, it is very time consuming and perceived as annoying. Your website might actually be usable to person A but not to person B at the same time, if they have different goals with their visit, or different preferences.

One way to get your users to agree that the website is useful is to design it with game mechanisms, so-called gamification, as it often gives a sense of purpose to what you are doing.

Gamified design

Gamification is an approach to designing useful services, not only what the user is able to do, but also understanding what needs to be done and why. Gamification is a popular term that discusses this in depth – how to use game mechanisms to give meaning and structure to a service.

It is not just about chasing trophies, medals or other digital awards, but usually a way to guide a user through a process or motivate them to do certain tasks. It is excellent for introducing new and existing users, but it does not have to look like a game – perhaps the competitive instinct or wish to please is more natural than we at first think.

When you launch a new website, how are you able to help or introduce it to your users? In the system, of course! The basics that need to be mastered are presented in a digital guide that helps the user to get started. Provide tips, motivate continued exploration and make the user feel safe that any setbacks will not be disastrous. This is called onboarding when talking intranet.

Gamification can be anything from a full-fledged game to a few cherry-picked game-components such as clearly stating to users what extra personal information they need to fill in to make the most of the service.

Things that distinguish a service that takes advantage of gamification include:

  • Relationships – a social context. How you relate to us? What others are doing?
  • Movement – incentives for the individual that feel neither like a carrot nor a stick. Why should I give away my e-mail and what is in it for me? What happens if I do not comply?
  • Feedback – continually know if you are doing the right thing and are heading in the right direction. Information in other words broken down into such small activities that they are hard to fail, micro-interactions.
  • Learn – how do you do better next time, is there something to improve?
  • Higher purpose – what is the service all about and why should a user get involved.
  • Reward – can come in the form of digital goods, such as medals or badges, but could just as well be something in the physical world. Maybe not the result but rather the effort put in is what should be rewarded. You should put some thought into this so that the game does not attract saboteurs. A good trick is to set an achievable goal everyone can relate to; when the goal is reached, you are finished. Sometimes there are multiple levels of reward like lotteries to see what you get, which gives extra excitement.
Figure 56: is clearly stating what tasks left for "12x more career opportunities" (2012).
Figure 56: is clearly stating what tasks left for “12x more career opportunities” (2012).
Figure 57:'s next iteration looked a whole lot different, with numbers instead of notes (2013).
Figure 57:’s next iteration looked a whole lot different, with numbers instead of notes (2013).
Figure 58: The circle illustrating the profile strength contributed to 20 % more complete profiles (2014).
Figure 58: The circle illustrating the profile strength contributed to 20 % more complete profiles (2014).

Some examples of successful gamification ideas:

  • The social job-related network got 20 % more of their users to complete their profile with important data. The change they made was to visualize how complete a user’s profile was with a circle.
  • The mobile operator giffgaff allows customers to offer support to each other. Customers get call minutes as compensation for their efforts. The company has around 16 employees who take on the more difficult questions and miscellaneous administration. This way, they can offer lower prices to their customers who are more active than competitors’ customers, which certainly gives some additional benefits.
  • Runkeeper, Nike, Jawbone, Fitbit, et al., who give regular exercise a social dimension where even daily (in)activity and targets are compared with friends. Social competition with the objective to exercise more, sleep better, eat more healthily and encourage each other.
  • EBay where the seller and buyer rates each other, for future buyers’ or sellers’ interests.
  • Slashdot has a karma system for comments on their articles. A user has to earn karma points. Only when you have points can you vote up or down on others comments. Many upvotes on your comments means you deserve better karma. Only those comments voted up are shown by default to visitors making it a self-moderating system.
Figure 59: Runkeeper encourages almost every single activity, with lots of sub-goals to celebrate.
Figure 59: Runkeeper encourages almost every single activity, with lots of sub-goals to celebrate.

One problem you may face when trying to take advantage of gamification is that you focus on what you yourself want the user to do. Instead, you should focus on what the user wants to do. The thing you, as a game system creator does, is to create game mechanisms so that the player wants to move along; you cannot suddenly change to a challenging tone telling the player what they must do. We are no longer an obedience society; rather we need to admit that our society is driven by motivation. To be told what to do can have the opposite effect. It is better of course to focus on why everyone wants to do something for his or her own sake.

Design and plan for errors that will occur

Glossary – error 404-page
The page that is shown to the visitor when requesting an invalid URL address. It happens when a page has been removed, the user mistyped an address or an error in an address sneaks into print etc. The number 404 is because of the status code of the Web protocol, HTTP, which signals that the page does not exist. Other common codes are; 301 meaning that a page has moved to a different address, and 200 meaning that everything went according to plan33.

Nowadays, you are not supposed to end up on a 404-page. That we so often do is partly due to lack of respect for the users’ best interests among us administrators who run websites. If a page on a website is no longer published, or if an address link is broken, I would claim that in nine cases out of ten, it is because one of the following:

  1. The page is about information in time, such as news or a calendar event. An often heard argument is to throw these pages in the trash since “no one should be interested anymore”, possibly “but it occurred last week” or that “it takes up unnecessary space”.
  2. They switched content management system and did not have the foresight to keep their established addresses. It seems to be easy to forget that the addresses on your website have value, for instance:
    • In the visitor’s bookmarks.
    • Search engines will not give you a golden star for your fine new page, as it is, precisely, new and unheard of.
    • Via the links to the page from intranets, websites, documents, or in people’s mailboxes, links that suddenly will stop working.
  3. Content management does not handle addresses in a good way. Most of the publishing systems I have seen have an address format reflecting the tree structure, a structure which mainly makes sense to web editors rather than to visitors. It rarely has much to do with the structure of the website. Frequently, you see that a main page gets a new name, then what happens is that all sub-pages’ addresses are changed.

For example:

If you decide to rename ‘Customer Service’ to ‘Customer Center’, all pages beneath it probably get new addresses. A more sensible handling of URLs is one of many things that have to be on the shortlist of requirements when choosing a content management system.

Clearly, there are occasions when you cannot cater for some visitors and they have to end up on a 404-page. In such an event, there are some easy tips to remember on how to design the 404-page, namely:

  1. Do not let it escape the visitor that the requested page cannot be found and that an error occurred.
  2. Make sure that the visitor gets a design similar to the rest of the website. It should include a logo, navigation, color and design.
  3. Give suggestions on ways to move forward. Maybe to list the ten most visited landing pages, or if the website’s structure is in the address that gave the 404-page, you can link to the parent page. Sometimes a search box is useful.
  4. Send the correct HTTP status code, a 404, to the visitor. If not, you can be punished by search engines and other robots.

If you do design a good and perhaps even entertaining 404-page, it can mitigate the initial disappointment that a visitor felt. When possible, refer to a new page that replaces the old one! The referring should be done with a permanent reference, a HTTP 301 technically, because all the alternatives are worse.

Figure 60: A faulty-configured web server might present unfriendly 404-pages.
Figure 60: A faulty-configured web server might present unfriendly 404-pages.
Figure 61: Spotify's cute mascot apologizes and suggests singing for money.
Figure 61: Spotify’s cute mascot apologizes and suggests singing for money.
Figure 62: Flickr acknowledges the problem and lets the user know that they are fixing it.
Figure 62: Flickr acknowledges the problem and lets the user know that they are fixing it.

Web, the mobile web, apps, or a little bit of everything?

For the near future, we will constantly be faced with the question regarding the packaging our information or services should have. Today, the question is most often related to whether there should be an app for specific devices or whether we should set higher standards for the existing website.

Just as many moved their content to social platforms, because it is where their target audience spends their time, our own mobile apps can become less relevant if the phone becomes a platform for starting up just a few services. That is the direction we are moving in, as it is becoming increasingly more difficult and expensive to get someone to download an app regardless of the fact that it might be both free and awesome. In contrast, maybe it is an app inside a larger application we should look at. For example, Spotify invites third parties to put “apps” in their app.

Usability guru Jakob Nielsen says, in his book Mobile Usability, that you should have a separate website for mobiles, perhaps even an app for the more frequent users and the unique type of usage patterns they have. That might be the most reasonable conclusion if you only prioritize usability and utility. At the same time, he speaks out against building websites for simple mobile phones, so-called feature phones, since the usability achieved is still so terribly bad.

Figure 63: Nice updates for those talking Polish or Italian, I do not, but I am still downloading this update somehow.
Figure 63: Nice updates for those talking Polish or Italian, I do not, but I am still downloading this update somehow.

Where apps are brilliant is where the web, in many cases, is not even trying to compete, such as with gaming performance on a mobile device, for instance. To some extent, it has historically been easier for those with disabilities to use apps instead of accessing the Web on a mobile browser. The advantage apps previously had was to be downloaded already and to cope without contact with a cellular network, something that websites are becoming better at.

Apps, by today’s standards, also have some drawbacks compared to a website. On a website, the publisher has full control and does not need to worry about customers using different versions where some even cease to work. If there is an error on a website, when you fix it, it is solved for everyone, and it is not necessary to notify all users that now you have improved support for the vast minority who have Icelandic as their mother tongue. Apps need to be, unfortunately, installed before you can make use of the content which is a bit like putting barriers around the entrance to your store.

In my opinion, it is very difficult to argue to lower the demands on a website, or by omitting to have them, and instead focus solely on an app. Apps have, thus far, had poor transparency through search engines on the Web, which means that you are hiding your content in a container that is hard to find compared to a regular, highly public, website. Apps are something that can complement a website and carry out some specific tasks more useful than what is profitable to do on a website. In most cases, you still have to build a website; it is foolish to create one that repels the visitors because of having done a half-hearted job.

Do not get blinded by the mobile market

Your mobile moment may never come. Instead, it may be that the percentage of visitors with PlayStation 4 will need your attention and what makes you lose visitors because of that, what you offer is not usable on a large television set. To rely entirely on web statistics to leave out certain groups of visitors is like planning a bridge for cars based on how many people swim the exact same route over a river.

Have you tried to navigate your website with a PlayStation controller?

Exemplified by the healthcare website, the number of mobile visitors increased each month during 2011 and 2012. The share varied a little since traffic from desktop computers depends pretty much on how successful the various campaigns are. At the turn of the year 2012–2013, almost half the visitors used a mobile device or tablet to visit the website.

Figure 64: The increase of mobile/tablet users (gray) at during 2011-2014. At the end of 2014, two-thirds were using mobiles while there was a very modest increase of desktop users.
Figure 64: The increase of mobile/tablet users (gray) at during 2011-2014. At the end of 2014, two-thirds were using mobiles while there was a very modest increase of desktop users.

When do you think became responsive or useful in mobiles? The responsive version was released in the spring of 2013 after months of preparation, when a majority of visitors were already using a device with a touch screen, about 42 % mobile and 10 % tablet. Given how quickly user behavior can change, it is extremely important to keep up with the change and make small adjustments on an ongoing basis to meet with visitors’ expectations. The time of large web projects is over; now the time has come to release improvements in a steady stream.

Your website is a magazine, not a book!

This book talks about the design of a website and the underlying information systems; it certainly scratches below the surface but it was only when writing these pages that I realized how much there is to think about. However, I will still pick a single subject about designing websites that is more important than anything else; namely that you from the very beginning are prepared to adjust the website, frequently. It is not about refreshing the design every five years and spending the time in between focusing on producing great content.

A website is not static print matter, since printed matter are things that disappear into oblivion, which is much better than a hopelessly outdated website that is all too easy to stumble upon. Every website should be more of a magazine that brings out a new edition each month.

This includes, of course, continuous web design. You should not be forced to implement any redesign project just because the design feels outdated, or because after two years of waiting with bated breath, you finally have a majority of mobile visitors, and then hurriedly have to produce a responsive design. All this is something you can do regularly and if you work according to a flexible project methodology, such as Scrum, there should not even be a particularly big change since each sprint actually releases new code on the website.

Between these releases, you design and conduct tests to decide if future improvements really are improvements according to actual users, following up on earlier activities and making sure that the plan for the next iteration is solid.

Continuous web design has the advantage that returning visitors are familiar with the design as each change is quite small. You need a proven master design with the most common graphical elements, what then is missing when building new is invented when necessary and tested on real users with A / B tests. That is what you include in your own pattern library, or what you would call your living style guide perhaps.

Glossary – deep links
Links from other sites to pages located far away from the home page of your website. Not your homepage, or the pages linked from your homepage or the main menu. These links are valuable signals for search engines as they suggest quality content that other people appreciate on your website.

The parable of a magazine also calls for ongoing work with content, curate what you have and produce new. This should hopefully lead to insight regarding the bad idea of giving up their content and making a fresh start – no matter if you change the content management system or not. Editors’ tools to produce content seem to have a stranglehold on public websites as seen by their visitors. We should of course not prioritize editors’ needs of tooling before that of users’ needs. Therefore, it is important to be prepared to change content management so as not to be caught up in a particular system’s proprietary standard, which in the future will make users’ experience suffer.

A typical example, which today finally seems to be resolved, is that content management systems tended to want to restrict how the addresses would look on the public website – and then, when you switch systems, you break all the priceless deep links procured over many years.

When a website is in constant change, you are better prepared for incidents, and everyone involved has more of the intricate details in their short-term memory. Furthermore, it is not a big obstacle to put technical updates onto production servers continuously. Sometimes it pays off at once when a security vulnerability affects the platforms and frameworks you are using.

Your website is always under construction, or at least it should be. Have a developer, web designer and frontend programmer readily available. Just as we do not wave goodbye to the marketing department between each marketing campaign, organizations should keep those skilled in web-tech nearby.

Continue reading: chapter 4, Web performance ›

Web Strategy for Everyone

Table of Contents