Five Steps To Redesigning A Business Website

February 26th, 2018 by Simon Bor

A modern business website has to do so many things at once. It's this strange mix of full page billboard ad, store front, order hotline, technical manuals, newsletter, and more. Our website has evolved over the years to deliver on all of these while keeping pace with our products and the devices we use. We recently launched a redesigned site that clears away a lot of old HTML cobwebs, and give us a fresh new look we hope our visitors will enjoy. Here are our top five tips to redesigning a business website (something any business should do, in some form, regularly).

We ended up here:

After starting here:

And here's how we did it.

1. Have Clear Goals

We had one overarching goal for this reboot: make it easier and faster for new users to find their way around, to understand who we are, and to see how our products can help them. We turned that into concrete steps for this first sprint (we've mapped out future sprints, just like we do for our products):

A simpler, cleaner navigation system that works equally well across all devices.
Completely rewrite and redesign the "front" pages of the site (the homepage, and the main product pages)
Be clearer about who we think our tools can best help and how
Update the look and feel of all public facing parts of the site (like a fresh coat of paint in your home, this takes longer and is messier than you think, but still quicker than knocking walls down)
Make the parts of the site we had changed load much faster, especially on mobile connections

2. Ship As Soon As Possible

Our list of goals was a pretty big shopping list. We touched / heavily changed hundreds of files to deliver it. At the same time we viewed this as a minimum viable change. Changing just the "front" pages would have made the rest of the site feel disconnected (see Windows 10 Settings vs Control Panel... 2.5 years in). Not changing the navigation would have meant when we did, every page would need to be reviewed and changed again. Our solution was a good compromise. At launch there are lots of things we still want to improve, but its better to release a better site now, than an even better site later. In the balance between quality, quantity, and speed, we kept the quantity in check.

3. Decide Who Should Build It

We've got this grand plan, but who should do the work? This felt like a classic case for outsourcing: someone to bring in fresh ideas and new design patterns, without diverting the team from our products.

So we decided to not outsource any of it and do it 100% ourselves. This makes sense, promise. Basically, it felt weird to think about another company creating our site. It's like asking a stranger to choose your cufflinks or jewelry for the day. No-one at Inflectra regularly wears cufflinks, but when we need to, we pick them out ourselves! So it is with our website. We wanted the website to really show who we are: in everything from the design, to the text, the feel, the icons, and the images. For a company who makes web apps it just makes sense.

We did it ourselves, but we didn't do this as a side project. This became the main job of the team (a mix of design, marketing, management, developers, testers) for the duration of the project -- roughly three months. It wasn't 100% all hands 100% of the time, but it was the priority project for all involved. This really helped push through fast and avoid tensions between competing priorities.

This was the right choice for us. Could it be the right choice for you? If you have all the skills in house (from design, to SEO, to development, to writing the words on the page) strongly consider it. Here are a few top reasons why (feel free to pitch these to your powers-that-be and let us know how you get on):

you can iterate really fast with only internal team members - no onboarding or explaining your purpose to consultants (after that really fun bidding process has finally finished)
you can get results that are uniquely you and gets everyone involved bought into
your website is as much a product your company makes and maintains as anything else, so why not show it the same love and attention?
you keep the design and technical expertise in house, which makes long-term maintenance massively easier (even once the redesign is fully 'done', there will be new features to add or changes to make)

4. Make Sure Your Message is Clear

If you're a software company, likely the scariest part will be writing clear, short, text that reads really well. If you don't have a Don Draper to hand, don't be daunted. Give it a try, and let your budding authors out. Write one really long paragraph about how great one of your products is, then pass it to someone else to rewrite, then someone else to make it half as long, then take another stab at it yourself. Try to not be precious about any phrase, or particular word. If you end up with something you all love: repeat, repeat, repeat.

The writing process was a long and hard one. For us, it was part of a year long effort to sharpen our public messages. It took lots of brainstorming sessions, thesaurus use, learning from books, and getting inspired by websites we really like. We started off being as clear as possible about who we are as a company, and what we're here to do (this involved just about everyone, not just the web team). That framed how we thought about our customers and our products, which led to more brainstorms, and more throwing text at a wall (literally - we use whiteboards a lot).

Here's a rough take on how we ended up articulating who we are (and who we've been since the company began):

We succeed only if we truly help our customers succeed
We help our customers through our products and supporting our customers use them
Our customers are a mix of testers, developers, and managers -- all of whom are involved in making software and applications
Our products focus, and will increasingly focus, on meeting the specific needs of those three groups and how they work together

Those four bullets gave us the high level context for how to approach writing new text across the website. It also helped focus us on areas where we can speak more strongly to those bullets in the future.

5. Build The Thing

Let's break this down into performance and features/content.

One blunt, but still useful metric, is page size. The home page of the old site was over 3mb (about average for a web page in 2017). It's now, with gzipping, almost 500kb (among the top performers for 2017). This is a massive improvement, but not nearly as important as actual page speed, which has more than doubled, and the gap is bigger still on mobile networks.

There are three main areas we worked on to improve these stats:

Images: this had the biggest impact on page size. Our top actions were:
1. reduce the number of images, especially large images
2. aggressively optimize each images by reducing the color depth, saving in the most effective format, making sure the resolution is not greater than the final display image needs to be (so no 1000x1000 png when the image on a page is only ever shown as 100x100)
3. have smaller versions of the largest images for smaller screens
4. use vector graphics (SVG) to control image size, reduce the need for images and multiple sizes, and improve clarity. We use FontAwesome and, where possible, use those assets as opposed to custom images, given FontAwesome is already loaded globally
5. consolidate any duplicate images, to ensure there is a single, canonical version only (e.g. for things like logos) - using SVGs really helped here
Javascript: this impacted page size and should have a bigger impact on performance on the page (though we didn't have much active javascript before). We moved to a very narrowly focused set of vanilla javascript functions, with no frameworks. Most of the site no longer uses either Bootstrap or JQuery.
CSS: in size terms this has stayed about the same, but it should still impact speed. We consolidated our CSS into fewer files, removed Bootstrap, and introduced our own in-house CSS libraries. This is largely atomic CSS, with some parts following a loose BEM methodology. This should mean that as the site grows, CSS won't need to grow that much.
Other changes: We spent quite some time optimizing fonts. This means making sure the newest browsers get the newest and most compressed formats. It also means reducing the number of fonts used on the site. We are also starting to explore service workers to better cache assets and allow for offline use of the site.

The above was only part of the effort by the team. Here's a few big takeaways from the developers/designers about designing the site:

Getting the site navigation right is worth a lot of effort. The site menus are the main way any visitor will get round the site, and are the parts of the site they are likely to interact with way more than anything else. The navigation needs to be clean, straightforward, and helpful to all users. Getting this right, especially across different devices and browsers is worth the investment. Given it's so highly used, it's also worth investing in animations on the nav more than other parts of the site to up the usability.
Treat pages, by default, as special, unique snowflakes. Templates (both HTML, and CSS based) can help rapidly scale a site as your content grows. These templates work until they don't. Then you end up making special cases, exceptions, and strange CSS selectors. A side effect of this is that the developer may prefer a less suitable design to avoid having to mess with the template. That's a bad result. We started off treating each page as a one-off, then copying parts of pages elsewhere as needed. This definitely makes it harder to change something across the site (say a header color), but lets us change things out on a single page very quickly and easily. Some parts of the site remain templated though (things like blog posts or press notices).
Designing responsively takes a lot of patience and flexibility. If you want to design for smartphones and huge screens then go beyond the obvious of 2 columns collapsing to 1 column. Think about how things like padding work differently on different screens, what font sizes work best on a smartphone, or even whether colors of font weights should change with screen size. Our CSS framework gives us tons of choices for fine-grained changes like these on specific pages for specific screen sizes.
Focus on the user experience. For us, this meant making the page easy to use and enjoyable to use. This was much more important to us than it being flashy. We keep cool JS based effects to a minimum, rely on CSS effects where possible (due to performance benefits), and kept the website a relatively straightforward website. Shocking we know, but we think the performance and usability gains are worth it.

That's a peek into our process. We hope it can help you on your own design or redesign project. If you want any more information about anything we've discussed, please drop us a comment below.