People frequently forget the most important thing while building websites:

Your customers are visiting your website because of your product, content or service: not to admire your design.

And for that reason, when you’re starting a project, it’s imperative to avoid letting yourself and your team to get bogged down in pure UI and visuals. By paying more attention to your content (both copy, and also structure and hierarchy), you’ll be able to serve your customers far better.

Each project is different, and design can be approached in a million different ways. But by building a workflow which is adapted to your own team skills, you’ll have a more powerful tool to use on your projects.

Here’s the process we’re currently evolving, here at Hanno.

Phase 1: Strategy

To design efficiently in the browser, you have to step back and start elsewhere. Whether that’s on paper, or in Google Docs. The overall goal with this phase is to have a clear idea about where we are going:

  • To know all the sections, bits and pieces we might need to include in the product.
  • To cover gaps and discover opportunities.
  • To research users, statistics, and behaviour flows.
  • To find out basic needs and desires from both the user, and the client, and to have an idea of how to meet those.

We produce style tiles and wireframes as well, which helps everyone imagine the basics of how the content will be laid out, and what to expect in terms of styling.

This is a collaborative phase with the client. We are working together using Google Docs, Basecamp and Hipchat. We collaboratively write and review the content to work out a proper content strategy.


When working to design applications, having a “traditional” content strategy, drilled down page-by-page, is unnecessary. Instead, we put together a UX Strategy Document, which includes:

  • user research and persona development
  • user surveys
  • long-and-mid-term product and business goals
  • information architecture
  • and user on-boarding
  • we also document key functions and interactions within the application, and describe when, and how, they should work.

By the end of the Strategy phase we have a very good picture in our mind (and in the document) about how the product will work and what we need to do to make it happen.

Phase 2: Rapid Prototyping

In the prototyping phase, we start building the website in HTML and CSS.

This is an iterative process where we start from broad and blocky prototypes, before repeatedly fine-tuning and gradually bringing everything we had in the UX Strategy Document into the design.

Our full rapid prototyping workflow is a topic for yet another post, but here are some pointers that we’ve found helpful:

  • We start by setting up the development environment using Vagrant, to get the whole team on the same page.
  • Usually, we use Bootstrap or Foundation for building up the prototype (and use it later as an MVP). These frameworks are easy to use, fast and extremely efficient.

  • Sublime Text is our favourite code editor when prototyping. Once you learn a few tricks, it becomes very fast to write front-end code.

  • Using BitBucket or GitHub allows us to easily manage the source code, and allow the client and other team members to follow changes at code level.

  • Wiring your commits and deployment notifications into your team chat (Slack or HipChat, usually) can keep everyone in the loop.

  • Setting up auto deployment via post-commit hooks is a great idea – whenever you push code to your development branch, it should deploy it to the development server so your client and team members can inspect it right away. We use deployhq to achieve this.

Want to see how to start with DITB? We are already working on our Step by step tutorial for setting up Vagrant with Bootstrap Sass, with repository autodeployment and hooks into your team chat. Signup to our Logbook newsletter at the bottom of this page, and we’ll send an update once we ship it.

These small tips can not just make sure everything is going smoothly, but also save a tremendous amount of time for you and for your client.

Since your front-end code will go into production very soon, it’s crucial to do frequent code reviews within your team – doing this ensures your markup is clean, readable and consistent.

Don’t be afraid to use additional tools to bridge gaps: BugHerd is great for logging small tasks and issues, and Basecamp for discussing broader topics.

We collaborate with the client constantly through sprints, until everyone is happy with the result, and all the major questions and issues have been addressed.

Without these tools it would be far more painful to produce quick, high quality, clickable and experienceable products.

Phase 3: Styling

Yes, we’ve finally reached the appropriate point to talk about visuals and how your website will look.

When we get to this phase, our content and user experience is shaping up strongly. The time has arrived to apply the whipped cream to the cake.

This is where most of the Sass code is produced. Based on our style tiles, we start layering out the design: starting with the basics, like colours and typography. Then increasing the detail as we iterate on sections and elements. Gradually the design starts to come together and our collaborative creative vision comes into focus.

We usually do several iterations on the design until we find it’s getting the desired reception in testing, and is good enough for a v1 ship.

Does it really work?

We are constantly evolving our workflow – if you want to read more about how it looked one year ago, go ahead and read this interview about our workflow written last June – you can see how much it has changed since then.

Some might argue that designing in the browser can’t produce high quality and visually impressive design work. To that, I’d point them in the direction of some of our own recent projects, which were designed entirely in the browser:

Others also agree with me on the importance of putting content first – as Alex Turnbull wrote recently on the Groove blog:

“I’m not disparaging good design; hell, I obsess over the stuff. But focusing on design at the expense of content can be deadly. To find a balance, we had to reverse course and put design in the back seat, taking a “copy-first” approach.”

When not to design in browser

Although we love DITB, we don’t brainlessly stick to it. There are some cases when you simply need to return using some design software:

  • Highly graphical websites simply cannot be designed in browser right from the start since the most important element is your visuals.
  • For large-scale, mobile or special-use applications, it might be efficient to use different tools as well, like Quartz Composer (as Facebook do).

And if you must design outside the browser to produce a mockup of a design, please do yourself a favour and use Sketch, which is a far better tool for designing user interfaces, compared to photo editing software like Photoshop.

The takeaway

Going with the traditional ‘visuals first’ approach, and having a fixed representation of how a website will look at the end of the project, before you start to figure out application flows and UX, might sound like a good approach, but it simply doesn’t lead to long term success and a great user experience.

The visual design of your website or web app is not something to gloss over – it is just frequently misplaced in the project lifecycle.

So I’d suggest a different approach: focus on your content first, build out a prototype around the best possible content and copy, and then allow yourself (and your stakeholders) to start discussing and thinking about look and feel.

By working with a far more iterative process, and delaying the introduction of visuals and UI, we can make sure that all the initial and intermediate design stages are managed and built properly: focusing heavily on the content and user experience.

Want to go deeper?

Great! Here are a couple of other posts to help you get started: