What's Next

Because style guides begin with the basic elements of a design, it allows us to share our work in progress from the start. In using this open approach with our clients, they can see the progression of their website from early on in the project. It also enables them to give feedback at the point in the project when it is much easier for us to accommodate change.

Building blocks

Web pages comprise of basic elements combined and laid out to create a user interface. Dave Rupert used the analogy of LEGO in describing how they designed and built a website for one of their clients.

The majority of websites that you browse have many common elements. These include color palettes, typography, navigation and buttons to name a few. We ensure that these elements remain consistent throughout a website by building a style guide. This helps to provide a better user experience.

Our style guide contains all the individual parts of our design system. It also shows you how they get put together to create the templates which you see when you visit a website.

Consistency over time

Over time, a website will change. This could be content that needs updating, more pages or new features. Because there is an existing style guide, we are able to determine the scope of work required in a short space of time. Our clients are able to view the style guide as it evolves during this update phase.

Code

One of the patterns in our website’s style guide.

Our style guides contain snippets of HTML used to mark up elements and patterns, whilst defining the code style we use. This makes it easier for our developers, as well as external ones, to add to the code base and maintain it. It helps to ensure our standards to produce consistent HTML and CSS.

The pattern library we have in our boilerplate style guide is up to date with the latest recommendations of best practice on the Web. It enforces what we learn from a project and lets us carry it over to the next one. This saves us time as we’re not having to deal with common issues that occur on the Web. The benefit of this is having more time to focus on providing solutions for the needs of our clients.

Design

Source: Interface Inventory by Brad Frost.

Over time, it is likely that the people involved with the initial design and build of a website would have moved on. If there is not a clear guide to reference, people may have difficulty in continuing the original design system. This is how inconsistency can make it’s way into a website and provide for a less than ideal user experience.

Your experience with a website is likely to be frustrating when there are inconsistencies in the interface. By having a style guide, you can prevent this problem.

Working together

The biggest change we’ve seen at Next since we started to create style guides, is that everybody is much closer to the project. No longer is development a “black hole” with the final product shared right before a deadline is due.

It allows for easier communication about and understanding of what we create. Potential issues get flagged early on in the process. Another massive benefit of the style guide is that you view it in a web browser. This highlights the complexities of responsive web design in a multi-device world. Our clients can then view the design in their favourite browser. This helps them to see that websites will look different on different devices.

The style guide we created for FRANK.NET’s website.

Resources

We love us some Wunderlist, but when you're in front of your computer, a CLI is a faster way to add a bunch of tasks or view your existing tasks.

Then, later when you're on your yacht you can open Wunderlist on your phone and check up on your tasks / complete them, or just admire them.

Features

Add a single task or task batches

List and filter all tasks

See your starred tasks

Open the web/native app

Screenshots

Clearly stated business objectives allow us to work faster by focussing our efforts on KPI’s that matter.

In the first month since launch organic traffic is up 76% month on month, Conversion Rate has increased between 60 to 80% across mobile phones, tablets & desktops and our speedy responsive design has increased leads by 32% & 35% on mobile phone and tablet devices respectively.

How We Did It

1. Performant Design

Analytics showed us that traffic to the existing site was split across a broad cross-section of browsers, devices and locations around South Africa. Our design needed to work across a spectrum of device sizes and had to account for the shaky connectivity speeds experience by South Africans daily. That meant curbing aspirations for slick transitions and sparkly JavaScript, and focusing on pristine, bulletproof markup.

Good markup pays dividends on so many levels. One of the most noticeable improvements with the new website is in page load times – it outperforms several of Standard Bank’s other websites:

2. Onboarding

Transactional aspect of the previous website were tedious to complete. We focused on designing a faster and simpler process for these to reduce as much clicking as possible.

UX and Interface changes had to be implemented without any changes to the DFS transactional web services – so for our first version we have kept design clean and straightforward while we develop and test additional approaches.

The focus for this launch has been on taking things away and giving FRANK the Frankness and clarity that made it famous when it launched.

The outcome is a responsive design, with solid performance benchmarks and an improved user experience that is already delivering improved conversion rates.

A Few Screenshots

For us the answer is pretty simple. The code is the means by which the strategy, the logic and the design is manifest. 

So sure, code is valuable. But the process we've built over 4 years that enables us to do that is more valuable and the people who solved the problem, designed the solution and created the code are invaluable. 

The solve everything at once mentality permeates our personal lives and many a boardroom, often setting us up for failure before we start and even worse clouding our view of what really needs to be solved.

We're far better at solving smaller problems. Maybe 50 000 years of evolution (where our biggest challenge was finding our next meal)  has failed us in that regard. But maybe making smaller,  better decisions on a daily basis is a strength.  Improving by just 1 percent isn’t often noteworthy (sometimes it isn’t even noticeable). But in the long run a few 1 percent improvements create a major force for change. As time goes on, small improvements compound and you suddenly find yourselves having taken a very big step towards solving the problem.

Marginal gains are like compound interest for projects, over time its the most powerful force for growth.

Even though we know that making marginal gains works, we don’t naturally embrace the idea or make it part of how we solve challenges individually or on collaborative projects.

Here are some thoughts why I don’t think we embrace marginal gains when trying to solve technology problems and what to do about it.

The Spec and the Budget

A spec document is often held up as the silver bullet, the piece of paper that makes everyone feel involved and happy to spend the budget. It’s what finance uses to approve the spend, it’s what managers use to hold everyone to account and it’s ultimately a “solve everything” way of thinking.

“Functional specs force you to make the most important decisions when you have the least information. You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making” – Getting Real 37 Signals.

At Next we don’t work to highly detailed Functional Spec’s rather we use discovery sessions, prototyping and actual users to form what we build. We hold onto our agile principles tightly and our opinions very loosely.

Trust and the invisible super hero

Marginal gains often aren't visible in the short term, you need to wait to see results. The problem is we hate waiting!

So instead of trusting the principles we write spec documents or buy off the shelf solutions in an attempt to give everyone on the project that warm and fuzzy feeling that it’s all going to be ok.  Creating Locked-in specs or using off the shelf technology often forces you to make big decisions too early in the problem solving process, too often leaving projects and products in tatters 6 months in. You have to trust the invisible super hero of incremental change.