This is a recap of a talk by Petter Joelson at Rabash’s Design Salon on February 19, 2015.

My agency Rabash was hired in 2014 to start redesigning Doctors Without Borders (Médecins Sans Frontières, MSF) Sweden’s website. The mission was to make the navigation intuitive, especially on smaller screens; optimise the donation interactions and enable moderators to create flexible campaign pages.

After the initial concept phase, I chose to start working on an early responsive prototype in html. Step by step, the prototype evolved to be equivalent to a full website. It might seem like a complicated process to make such vast prototypes in html, but I have learnt some tricks to make it quite easy. I have also seen three major advantages in this way of working, that I will walk you through one by one.

1. Responsive

Show the client how the website will look and behave.

Since responsive design came around a few years ago, I have worked according to the Mobile First-principle, and started the design process with wireframes for mobile screens. It is often an illustrative way of showing the client which priorities they have to make for the website to be easy to navigate. But it started to feel more and more impractical to show mockups of a page that does not look like the end result at all and can not be tested in its ”natural environment” which is the browser on a phone, tablet or desktop. This makes it unnecessary hard for the client, and even me as a designer, to envision the functionality and look of the final product.

Having to write complicated code just to show a quick idea for a client would not work for me. My first criteria for prototyping was that it should involve as little coding as possible. And even as front end development has become more and more specialised and complicated over the years, there are now more and more easy to use frameworks for building websites and other digital products.

A couple of years ago I started to experiment with simple prototypes in html. In the beginning it was just static pages built with Bootstrap. When I got the hang of it, I realised that it was actually as quick as drawing page by page in a wireframe app. For example: if I changed the height of an element at the top of the page, I did not have to move every other element; if I wanted to change the size of all headlines, I only had to do it once.

Now I use a combination of Bootstrap and Jekyll, with a few minor plugins that I install with Bower.

2. Modular

Give clients a custom design system with which they can modify, extend, and grow with into the future.

Brad Frost

A few years back, it was a really big deal when you every three to five years launched a new website. After the launch the sites became more and more out of date, until you did a complete redesign again. Most people understand now that their website has to be a living thing that evolves over time, in small adjustments, to stay relevant to users.

So how do we adapt to this workflow in the design process? Brad Frost advocates a method that he calls Atomic Design. He breaks down the design into smaller components to be able to present the client with a comprehensive design system, not just mockups for specific pages. Frost uses five levels for his design system:

• Atoms: A single button or headline
• Molecules: A search field with button and textfield; A byline for an article
• Organisms: A campaign area, menu or list of news
• Templates: The page template for news articles
• Pages: Complete pages like About or Blog

To showcase the design system, Frost has developed something he calls Pattern Lab, that provides a kind of responsive style guide, documenting all parts of the website.

Inspired by Frost’s Pattern Lab, I developed a documentation for the different components of the website for Doctors Without Borders. It made it easier to explain to our AD which components needed graphic design, and the structure of the website became clearer for our developers.

For a vast project like this, it also made the whole workflow run smoother, as I could get an approval from the client for specific components, before the whole page template was done.

3. Content first

Separate content and presentation

A challenge with the new design was making huge amounts of information accessible on small screens. To achieve that, I needed to start with the content, and not make the mistake of building a perfect website, that get gets ”ruined” when the actual content is added.

The advantage of working with a system like Jekyll is that you can make a complete separation of design and content. The content files, using Markdown, are super simple text files that only defines the content, fields and template to use, nothing more.

That enables me to be able to work separately with the content, let a copy writer or the client go through the texts during the prototyping phase, and avoid surprises in later stages.

The prototype for Doctors Without Borders is nearly a complete version of the website, as I define templates in Jekyll and then only need to add ”raw” content.

From the prototype, I was able to generate a documentation page, that lists entry pages, types of articles, components and menu items.

To be able to make this separation of content and design is extremely valuable for responsive design. When the next gadget with a browser arrives (glasses, watches and so on), you will have the content files ready and can focus only on designing the presentation.

Next step: Integrating design and development

During this process, the prototyping has evolved parallell with the graphic design and the development of the final website. My aim for future projects is to better be able to integrate these processes, and be able to create both design and functionality in an iterative way and in dialoge with the client. When the CMSes become easier to work with, and the software for graphic design are better suited for responsive web it will of course get easier. But until then we need to experiment with ways of making the transitions between design and functionality as seamless as possible.