The design process (is not a flow diagram)
Everyone likes diagrams, and everyone likes lists. Lists are easy.
The process of designing websites at Substrakt, however, is not a neat production-line-style flow diagram; it doesn't follow a linear set of steps.
If someone shows you a neat conveyor-belt design process diagram when they're describing designing a website, they're lying in order to draw a pretty picture. They're likely drawing said picture in an attempt to describe their (or their companies') creative process to a client, or to demonstrate to their peers. A typical 'design process' often looks like this:
We sketch our ideas out on paper
We take these sketches into wireframes
We take these wireframes into Photoshop/Sketch
We create polished designs and get the client to sign these off
We hand these over to a developer to be built
Spinning Plates
I find the harsh reality is more a chaotic spinning of multiple plates, but I'll try to describe and put something on those plates:
1. IA (Information Architecture)
The structure of the site. How it works. Look at the current site, the current content. Decide what should stay and what can go. What will be added. Consider theming and arranging content based on the user (we will get to that) rather than departmental silos.
Things to keep in mind for navigation:
- Less is more. (The tyranny of choice).
- Navigation labelling based on short, layman terms and verbs, rather than ambitious internal nomenclature.
2. Visual Design
I purposefully placed this second, though I know it is where a lot of designers start: how it looks.
This takes into account any brand identity guidelines - including fonts, house styles, assets & elements that may exist, or be created afresh, suitable for the organisation. These are incorporated into the design - where appropriate - without compromising the IA. Carefully consider context - there's little point in designing a minimal masterpiece if the site will be content heavy. Design based on real content, not tailored placeholders.
3. User Focus
Keep users in mind throughout decision making - 'will this make sense for the user?' What do they really want to be able to do on your website? Is this design suitable for the audience? Draw from your the experience working with similar audiences on similar projects, as well as workshops, research, analytics, and asking them.
Fulfil those needs first, before offering deeper, experiential based content.
Remember your user is likely on your site for a specific aim: to book a ticket, to ascertain some nugget of information - for example: what time are you open on Tuesday?
Don't obfuscate those tasks with your ego. '*We want our users to x' *is often a selfish desire.
Outputs
These days, we have no hard and fast rules about design 'deliverables'.
These can range from sketches, rough wireframes, barebones designs, polished designs, prototypes in Marvel/inVision, in-browser static html/css mockups, or, more likely, a mixture of these. Where possible, we look to creating in browser mockups using actual html/css as soon as possible - there really is no better way to assess the validity of design decisions than in the medium in which the site will be consumed.
It's also the quickest way to test real content and, perhaps more importantly content mass - two example content modules with one line of lorem ipsum in Sketch does not represent real world use, if that section will in fact contain 20-30 of said modules, all with different amounts of content in. What looked neat in flat mockups could soon become unwieldy. On reflection, these modules could be smaller. Do we change the size of them? What happens to the grid? Does it allow for content overflow? Do we add content overflow handlers, i.e fading out of content at certain dimensions? Do we terminate line lengths and add ellipses?
All these considerations come to bear much earlier in the project lifecycle if they are tackled in front end code.
With a strong command of html/sass, as well as structuring your code and classes to follow paradigms such as BEM and ITCSS, in-browser prototypes can often be as quick, if not quicker than spending hours/days/weeks painstakingly setting up nested symbols in Sketch. Our workflow often is a hopscotch between in-browser mockups and rough idea generation in Sketch. The added benefit here is that some of the foundation build work has then been started. Front-end build time is then spent refactoring, iterating and improving this front end code, rather than starting from scratch.
We take this approach not to be different, and not because it's easy (it's not), but it keeps us alert.
We take steps back (and forward) to test our decisions, rather than ticking linear boxes and letting the process lull us into a false sense of security, only to find issues rear their head later on. ** Dogma is comforting, and in this business it goes by many names.**