Good responsive web design, by its nature, goes unnoticed to those consuming content online. So when someone asks for a new website, they’re often completely unaware of the concept, despite experiencing it on a daily basis. And yet, responsive website design is now acknowledged as standard practice throughout the industry. Building responsive websites has altered our processes, from creating mockups of complete pages, to building libraries of reusable components and layouts. [pullquote]layout is content-driven and styles are brand-driven[/pullquote] Recently we were approached by an existing client to responsively redesign their website. We’d previously worked with them using a rigid waterfall process. Moving to an agile workflow, we were able to embrace change at any point in the project. Throughout the process we adhered to the philosophy that layout is content-driven and styles are brand-driven.

Wire-framing the specifications

Specification documents work great for listing out all the functionality a site is required to have. But is it really what the client needs? It’s very hard to visualize these features in place. Thus the result is that specification documents often turn into bloated wishlists. This doesn’t help the client, designers, or the final website. Instead of specification documents, we opted to use wire-frames. The first step of the project involved creating wire-frames for every page. This may sound like overkill, but the wire-frames led to early discussions of the content and features for each page. We found that features that we never considered before were added, while many were removed. Wire-frames gave us a clear, visual representation of how content and functionality should be prioritized on each page. These wire-frames then became a reference point, replacing a specification document. Key takeaway: producing wire-frames in place of specification documents focuses everyone on the core features and the importance of content.

Auditing

Auditing the wire-frames allows us to form a list of all the common components. Across a single site there will be dozens of small sections on each page that are very similar. These components can be collated into an exhaustive list which will be used later on. This stage has three main benefits:

• It flags any discrepancies in the wire-frames. Think of it as proof-reading the wire-frames. Some areas may be different for no real reason. We can tie the whole site together before we start building unnecessary components or layouts.
• It helps keep all of the front-end code as lean as possible. Planning how the CSS will be structured has become vital on large projects. We want the website to be as fast as possible and structuring the CSS early on helps this.
• Large websites will involve multiple people at any time, both during development and in the future. Creating maintainable code is important for the project moving forward.

Key takeaway: planning how to approach the front-end development of a project is important to create a maintainable, lean code base.

Pattern libraries

Pattern libraries are a collection of common elements used on a website. By focusing the front-­end development on building components that are not dependent on pages, we can reduce the code overhead and improve consistency. Using the list of components we collated during the auditing stage, we are able to structure our Sass into a manageable collection of files.

Naming conventions are important

We’ve used pattern libraries on a few projects but have always struggled with naming conventions, particularly the folder structure: where do you put your styles for this music player, in components, or in partials? Previously, we’d been using terminology such as partials and components to organize our Sass files. While these seem like completely legitimate naming conventions, they are open to interpretation. When there are multiple developers working on a project, leaving the organization of the code base open to interpretation leads to unorganized CSS. BEM (Block, Element, Modifier), provides us with a common convention to follow, and creates an understanding between front­-end developers. The old way was left to individual developers to come up with class names that were all too high-level to glean any meaning from. Fortunately we were lucky to see Brad Frost speak about his pattern library at the Upfront Conference in Manchester. Pattern Lab lends terminology from chemistry to describe the components that make up the library. Using atoms, molecules and organisms to describe the differences between components on a page helps explain the concept to developers new to the project.

Atomic design is for user interfaces: http://t.co/eEZSYeK5VF You can apply atomic design to any UI, like Instagram pic.twitter.com/BrztgtRoGU — Brad Frost (@brad_frost) July 10, 2015

Atoms - the essentials

In nature, atoms are the smallest denomination (unless we delve into quarks and electrons). In web development, atoms are the most basic elements of HTML. To all intents and purposes they don’t do much on their own. These include headings, paragraphs, inputs, buttons, lists…You get the idea.

Molecules - scalable patterns

These are the next layer up. In chemistry, molecules are made up of atoms, and the same applies to the structure of CSS. Molecules are components on the website that use atoms to form them. A good example of a molecule is a search box. This contain 3 atoms:­ a label, input and button. The molecule layer starts to form some of the elements we can use on the website. It’s important to make all of these molecules scalable. They should be designed with the idea they could be used anywhere on the site. Our ultimate goal to make the CSS as flexible and reusable as possible.

Organisms - collections of patterns

As the name suggests, organisms are groupings of molecules. Some examples of these include a header, footer, or list of products. If we take the example of a header, this would include a logo, search, and navigation. These were all created as molecules and are combined to form a header organism.

Templates - The glue of a page

This is where the biochemistry analogy ends. As Brad says, “get into language that makes more sense to clients and final output”. Templates are the glue of a website. These combine all of the organisms we’ve created into a layout that could be applied to a page on the website. An example could be a blog listing. This template would include a header, footer, a list of blog items, and a sidebar. Templates are generally structural, containing only the layout.

Pages - Handling variations

The final section is pages. This is where you can test the templates with real data. Pages are specific instances of a template. This part is important because it allows us to see how successful the atoms, molecules, organisms and templates have been. It’s inevitable that when building the website, certain scenarios will be missed. The classic example is long titles, or catering for different currencies and languages. Key takeaway: Naming conventions matter. Layering CSS creates a clean codebase to work from that is as small as possible.

Designing with flexibility in mind

Designing patterns is hard. You can’t design an isolated pattern such as a news item, and expect it to fit with the rest of the page. The way we build websites and the way we design them differ. [pullquote]Designs are likely to change regardless of whether we get sign-off…Sign-off became an irrelevant step in the process that only put pressure on both sides[/pullquote] We used Photoshop to create mockups of the wire-frames with these styled components in place. Once we were happy with the look and feel of the designs we moved to isolating each component. This allowed us to ensure each component was flexible enough to work anywhere on the website. We were very conscious to not get sign-off on any design work. Design sign-off creates a barrier where the designer feels pressured to create something that will be set in stone. Designs are likely to change regardless of whether we get sign-off or not. Generally we are happy to accommodate any changes at any point in the project timeline. Sign-off became an irrelevant step in the process that only put pressure on both sides to the detriment of the relationship.

Move from Photoshop to code quickly

Knowing when to move from Photoshop to code is important. This step is much earlier than we were used to for two reasons:

1. Perfecting layouts in Photoshop is time consuming and ultimately a waste of time. Time perfecting the website is better spent at the end, on the actual code.
2. It creates a reference point for what the website should look like. The reality is, it will never look identical; but once a client has seen (and perfected) the designs, an expectation is created.

Instead of spending additional time in Photoshop we opted to invest the time in code. If we should perfect anything, it should be the code, the bit that will actually be used and seen by all the website users. For us, Photoshop was a tool for creating a design style that could be used across the website. Design is much more about collaboration between everyone on the team. Mockups were still a very important part of the process, helping the client to visualize how the site would look. If we were all happy with the general direction of the design, we would move it to code. We rarely spent time going backwards and forwards making amends to Photoshop documents. Key takeaway: Photoshop is a great tool for creating design concepts. Moving to code as soon as possible is important. Perfect it in code, not Photoshop.

Iterate for better usability

The beauty of this workflow is there are so many places to review and improve the website. It is important to note that these are loose steps in our project process. If we need something new during the project, we will generally treat it as a standalone, modular component that can be dropped into the website and adopt the design theme of the site.

• At the wire-framing stage we plan the project
• At the auditing stage we review and improve the wire-frames
• At the design stage we mockup a design style
• At the coding stage we integrate it all together

Each of these steps offers a point where we can review our work so far. It also allows for a fresh set of eyes to see things from a different perspective. During any of these stages we may find that some parts aren’t working as well as expected. This is okay. In fact it’s good. Catching poor usability early is key for a successful website. Going back and wire-framing these parts of the website will make the project better when it goes live. Key takeaway: Don’t be scared to go back to the beginning if something needs improving. Catching these early will make the project better when it goes live.

The finish

We spent days working together to ensure every part of the website was finished to a high standard. We tested as many scenarios as possible, ensuring the browsing experience was consistent. Once the data is in the website we are able to fully test the website. It’s often too easy to set a project live without fully testing. We can check the speed, ease of navigation and most importantly the purchasing flow. Everyone mentions Apple for being perfectionists but I am sure their first attempts were far from perfect. It takes time and dedication to make those final improvements to give us the products we love today. Using our device lab, that includes most of the popular devices and platforms, we were able to ensure that the experience was the optimized on as many of the latest platforms and screen sizes as possible.

Retrospective

Learning from each project is important so we can continually improve processes that lead to better websites. This project saw the birth of our own in­-house pattern library that encourages consistency between projects. When working in an agency, we may have dozens of projects currently in development simultaneously. The ability for anyone to work on any project is important. Creating a base we can all work on will help contribute to this goal. The performance of the website was only considered towards the end of the project. A successful responsive website needs to be lean and fast. The huge range of devices and their capabilities vary massively from brand new Mac computers to old smartphones. When building a media rich website is can be very hard to manage the performance, especially when retrospectively trying to improve it. At Upfront Conference in Manchester, we saw Yesenia Perez Cruz speak about considering performance at every stage of a project, including design. In hindsight, this is something we should have implemented. As a team of multiple designers, developers and front-end developers, managing the overall size and performance (particularly the perceived performance) should have been a bigger priority. Everything on a page has a cost for performance. Prioritizing what is important ensures the website is not only fast, but accessible to more devices. On some older devices, we found that the website crashed not just the browser, but the entire device. Trying to speed up the website retroactively meant we couldn’t make the website as fast as it could have been. Next time we will make sure performance ingrained into every stage of the process, so it isn’t an afterthought. Featured image, code image via Shutterstock