Process

It's not uncommon to meet a client who has a hard time describing what they want their website or application to look like, or how it should work.

In fact, sometimes it's pretty darn difficult for experienced heads to articulate the visual and functional aspects of an organisation's identity, purpose, and business processes.

To overcome this seemingly brain-numbing thought process, I prescribe a structured procedure to direct production from concept to launch.

.01 Understand

In order to successfully complete a project, first we seek to understand the actua problem, as well as to get a sense of the client's favoured aesthetic outcome.

This is great for outlining clear project objectives and constraints, and for creating a casual environment to stage discussions on functionality without fearing the prospect of a technical conversation.

.02 Define & decide

By interrogating the website's different interest groups (their motives and browsing habits), I can uncover key insights about what needs to be built, as well as the kind of interactions they might expect.

This could also be a good time to pull out some paper and a marker and start sketching out a skeletal structure of our limited-scope interfaces.

.03 Discover

Talking about things like typography, imagery, colour, layout and navigation without getting mired in specifics can get pretty tricky. I use and mood books to guide style discovery conversations in a "show and tell" exercise. It's also a great tool for educating clients about design concepts, and what to consider in the process.

.04 Branch off

With an informed outline of the core features and functions of the website, I can confidently start drafting sketches of the visual structures for pages and sections, navigation, and other elements that hold text and multimedia content, or drive user interaction.

The idea, here, is to create a set of low resolution designs that represent the structure of an actual web pages.

.05 ...then circle back

Reviewing and deliberating multiple layout options with clients increases design clarity, and helps to validate both concept and functionality. If the cream starts rising to the top at this point, I can safely chaperone them to the next step!

.06 Style guides vs mockups

Next I'll produce high definition mockups of the sketched-out layout; focusing on creating reusable modules that could be dropped into any unitary page if the situation so fits.

Each module exists free from the general page layout, but not independent of a deliberate design language. It is largely informed by the ideas from earlier conversations using mood boooks, sketches and wireframes.

.07 Into the browser

With a designated group of style guide elements ready, the next step is to render them as repeatable components using HTML, CSS and JavaScript, and begin incorporating these into specific page layouts scoped out earlier in the project.

I'll employ a number of front-end concepts like object-oriented CSS and atomic design to costruct what are essentially "user interface bricks" –– each reusable in an array of layout contexts, yet remaining effective as an individual part of the browsing experience.

It's always improving

While this process works pretty well for most projects I've been involved in recently, that doesn't mean it's going to be perfect for everyone, nor for every website build I'll ever get my hands on. I like to think of it as getting a good foothold on what's important, then adding and removing steps in order to get from idea to product.

See my work