Every studio has its own way of working when it comes to the design process. We’ve recently explored how best to update our existing design process to better suit the needs of a growing team.
Putting steps in place creates clarity and consistency across projects but we were also conscious not to inhibit any one member of the team - because we all have our preferred way of working.
Our design process now revolves around three tools. Sketch, Abstract and Tailwind. Each tool plays a key role in taking a project from ideation through to front-end development. Here's a run-through of how we're currently using each tool here at Club.
Sketch remains our design tool of choice. Whilst there are plenty of similar tools vying for space, Sketch is ideal for much of the work we do.
We currently have five 'starter' Sketch files that are used during the design process.
- Sitemap Starter
- Wireframe Starter
- Wireframe Components (Shared library)
- Mockup Starter
- Tailwind Palette (Shared library)
A sitemap is a good starting point for any new project. It works out what we will need to design, what a typical user journey might look like and ensures everyone is on the same page ahead of the wireframing and mockup stages. Our Sitemap Starter document contains all of the components required to construct a comprehensive sitemap in Sketch.
With the sitemap agreed, we then move on to creating low-fidelity wireframes. As mentioned in our previous post about our design process, creating purposefully low-fidelity wireframes makes it obvious to all parties that final design decisions have yet to be made.
During this design phase, we are focused on mapping out the broad layout of each page and considering the flow of the website or application as a whole.
In order to keep the wireframes focused and make the process generally more efficient, we use a shared Sketch Wireframing library that contains reusable components including buttons, forms, text block and images. If a new element is required, it can be added to the shared library for use across other projects.
We then take wireframes and annotate them within Sketch - we pick out the key aspects of each page that we want to highlight during presentations. This also gives us the opportunity to explain our reasoning.
Once the sitemap and wireframes have been approved, we move onto mockups. By default the Sketch Mockup Starter document contains the following pages:
- Colour Swatches
- UI Kit
- Ideas Canvas
- Responsive Sizes
- Desktop Large
The above structure helps us get up and running on a project quickly. It doesn't exist to impose any design decisions, but rather anticipates the setup that is required before any mockups are created. We know we'll need to set up a grid, define our text styles and create reusable symbols such as buttons and input fields, so it makes sense to have some boilerplate content in place to speed this up.
Finalised designs for the various breakpoints live in the 'Responsive Sizes' pages. The 'Ideas canvas' page can be treated as a playground - a place to try things out before refining those ideas in the final designs.
Structuring each Sketch document in this way provides consistency between projects and ensures everyone involved in the design process knows where to go and what to look for - particularly during the development phase.
Tailwind is a utility-first CSS framework that is ideal for building websites and interfaces quickly. Unlike Bootstrap or Foundation, Tailwind does not impose any design constraints, nor does it make any assumptions about how you want something to look.
To take our designs from Sketch into code we setup our Sketch document in broadly the same way that Tailwind is configured. This creates less room for discrepancies between the design and the code.
For instance, in our Mockup Starter Sketch document, we have symbols that can be used to define how much spacing there should be between elements. This spacing then maps to the margins and paddings as defined in our Tailwind config. This makes life easier for the developer as they can see which Tailwind class to use in order to define the correct amount of spacing - less eyeballing, more consistency.
Tailwind is quickly gaining traction within the development community and we're excited to see where the framework is headed. We're using Tailwind across all new front-end projects - it speeds up the development process and provides a solid foundation for producing mobile-first designs. It also has the added benefit of providing code-familiarity across projects - so even if you were not the person to initialise the project, the Tailwind utilities classes will be far easier to interpret, which makes getting up to speed much less challenging.
Tailwind comes complete with an extensive colour palette that can be used in projects - outside of any brand-specific colours. You don't need to use these colours and you are free to change them, but they are useful nonetheless.
Our shared Tailwind Colour Palette library allows anyone to access an up-to-date copy of the entire Tailwind colour palette from right within Sketch for use in their designs.
Default Grid System
By default, we start with a 12 column, 8-point grid system. Adjusted to 8 and 4 columns for tablet and mobile respectively. Whilst the nature of the design or project can dictate that a different grid is required, we find this is a good starting point.
By defining an 8pt grid system, it becomes far easier to create a consistent user interface and one we know that from a UX perspective, is tried and tested.
Our Sketch doc is setup to nudge in increments of 8px and we have reusable ‘spacer’ elements that can be used to quickly check or define the correct spacing. This spacing is then directly mapped to our Tailwind configuration in the form of margin and/or padding.
It is also well documented that the 8pt grid system helps to establish a clear vertical rhythm.
Abstract is a relatively new tool that bridges the gap between design and development and allows for a smoother handover. It places all our Sketch files under version control - if you’re familiar with Git, think of Abstract as Github for design.
You have a single ‘master’ Sketch doc from which separate branches can be created. In order to make changes to the Sketch file, you must first create a branch - Abstract doesn’t allow you make changes directly to the master document.
As with Github, working in a separate branch is good practice and allows multiple team members to work on the same design project before brining everything together in the master Sketch file.
If you have finished working on a branch and want to get feedback from the rest of the team, you can request a review from within Abstract. That will notify the relevant team members who can then review and critique the proposed changes.
...if you’re familiar with Git, think of Abstract as Github for design.
Once a design requires feedback, we export the files as PNG’s and they live in Google Drive - you can read about how we use G Suite to manage and organise projects here.
It’s good practice to get feedback regularly. Otherwise, you risk becoming siloed in your own work. We’ll share designs across the team often and then schedule regular, more formal feedback sessions - we do this with the help of our Apple TV in the office.
Anyone within the team can see the current status of the design either via Google Drive or through Abstract. For client feedback, we deliver designs via email, in Basecamp or over a call.
Clickable prototypes often prove valuable as they provide a much clearer insight into how a website or application will work once built. It makes it easier for clients to explore the designs as a whole and exposes possible pain points in a design that we can recognise and tackle before the development phase commences.
Sketch supports native prototyping which makes it easy to fit the process into our workflow. You can stitch link pages together, apply transitions, and use Sketch Cloud to share the prototype with others.
Whilst we're happy with our current design process, we always keep an eye out for new tools and services that might help to further refine our design workflow.
If you have any thoughts or recommendations please let us know, or if you have a design project that you need help with, we'd love to hear about it.