Make Website Design Decisions in Your Browser: My Process for Designing Websites

View all articles

A lot has been said about different approaches to website design. With the rise of responsive design as an industry standard, our approach to designing websites and interfaces has changed as well. In the past, the process was streamlined in stages (such as planning, wireframing, designing, slicing, developing, testing and publishing). Nowadays, with device landscape changed as well (mobile phones, tablets, laptops, desktops, and even watches) it’s a lot harder to keep everything consistent and functional across all devices.

website design

We don’t have the resources to create a static design of one component (let’s say a header or a footer) across 10 different resolutions and viewports. Even if we design for the most popular devices, we’ll have to think about 4–5 screens with different aspect ratios, screen density, or screen estate in general. This is easier said than done.

When Designing Websites, Most Problems Can Be Solved with Paper and Pencil

Before we continue, I’d like to explain my design and planning process to better communicate my point of view. I start with a questionnaire for the client with different questions concerning the target audience of the project, strategies, expectations, and more. The better I understand the project and the client before I start, the more efficient I’ll be later on.

Next step is writing about the project to see if I understood the concept. This is helpful when working on projects in a niche where you don’t have much experience. Sort of like a functional specification, but less technical. It comes handy to define terminologies, keywords, and processes. Depending on the project complexity, I’ll probably do several scenarios and user flows. Usually the user onboarding flow, creation of content (if it’s that type of site), a checkout if it’s a webshop, or whatever is the specific kind of project I’m working on.

Next, I’ll start to produce a mood board, collection of things I like on other sites, colors or fonts we might use, icons, images and so on. If the client has a branding guideline, now would be a good time to explore it and talk about style.

You should do an interface inventory at this point. Brad Frost has a good article on that and a quote from his article really sums it up nicely:

An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.

If you are doing a project from scratch, then you can start by writing all components and elements that your project will be built from. An unordered list will do just fine (definitely better than nothing).

Prototype Sooner and Avoid Problems in Development Later

Prototyping is the next big phase of every project, and I often start with pencil and paper. Building quick wireframes to talk about the layout and functionality is a good start. It doesn’t cost much time to build dozens of wireframes of different templates and components, but depending on the complexity of the prototype I might use apps like Balsamiq, Moqups, or even do a clickable HTML prototype.

If the prototype is a success, I’ll do some components or templates in a design program like Photoshop or Sketch. I pick one of the more complex pages that include different interface elements (e.g. navigation, header, footer, product listing). I’ll play with different styles, icons, and colors based on the predefined mood board. The purpose of visual design is to explore what a finished design might look like, keeping in mind that I’ll probably change it (for the better) when it’s built with HTML/CSS. Prototypes vary on the project, and I don’t always follow the same approach and might combine multiple techniques or programs into one project.

Designing in the browser is a term that became popular with the rise of responsive web design. In order to minimize hours spent in design programs like Photoshop, designers were urged to move the design phase into the browser by utilizing CSS. I’m quite fond of this approach, because it proved more efficient in my experience. In my case, the deliverable is HTML and CSS design, viewable and usable in the browser. To learn why, keep reading.

Exception or a Standard?

By focusing on the HTML mockup and testing design ideas in–browser with CSS, we save time we might usually spend in Photoshop or Sketch doing static mockups. For best results, I recommend you equip yourself with a good code editor and browser refresh method so you can see changes in real time as you type them. I rely on Sublime Text and Codekit combo, although there are other options available as well depending on your preference or operating system.

designing websites

HTML and CSS, structured as they are, forces us to think about patterns and keep us in check. It’s easier to think about modularity when you are building HTML components that can easily be copied, duplicated and filled with dynamic data while keeping the same structure. If you want to create a specific modification, you have to explicitly target that element or add another CSS class. When you style headings, they will be consistent across the site unless they are overridden. Same goes for other elements. This type of thinking forces you to standardize, group common elements together, reuse already styled elements as much possible, and most importantly keep everything modular.

With a single CSS declaration, you can change padding on buttons for better touch targets and test directly on a mobile phone, tablet, and desktop. This can’t be easily done in Photoshop or Sketch, because other elements are not aware of each other in layout and you would have to reorganize objects each time you change something in size. Want to try out a different header color scheme? Several lines of code and changes are visible on all HTML templates on all your devices and screens. That kind of flexibility for exploration can’t be emulated easily when you have 20 static mockups. Granted, you could use smart objects in Photoshop, or Symbols in Sketch for components but it’s not as versatile as CSS.

The Internet would have been very different if web browsers were just PSD viewers.

In this phase you will have to make several technical decisions. The weight of these decisions will influence the quality of the design. Some of the questions you will need to answer:

  • Will you use a CSS preprocessor? (You definitely should)
  • What type of grid will you use for the layout?
  • Are the fonts you want to use available for purchase, does the client even have the budget for premium fonts, or will you revert to using available free fonts? More importantly, how does that Font render on screen?
  • Will you be using multicolor or single color icons? Will the size vary throughout the site? Following, are you relying on custom drawn icons or on an already existing icon pack? What sizes will your icons need to accommodate?
  • … and many more.

Trouble with Fonts

Choosing fonts for your project can be challenging. There are many possibilities and as much constraints that you become aware when you need to choose font delivery approach. Since the design will be used in the browser there is no better place to try out fonts. Font readability can vary based on the size, weight, colors, rendering — so by trying out fonts directly in the browser you are making sure that desired expectations are met.

There are many tools online that you can use for testing fonts and trying out combinations. My personal favorites are Typetester and Typecast, where you can test different fonts from various services and foundries. If I’m working with a specific font subscription service like Typekit or Fonts.com, I generate fonts and test on my own templates directly. Generating a Typekit package with new fonts is really simple and fast, and you get to see how the font will affect performance of your page as well.

Icons That Fit Your Style

If you decide to draw icons by yourself you will need to define size, grid, and style. I do all my icons in Illustrator where every artboard represents one icon. You can easily export icons from Illustrator as SVG or PNG, which can later be turned into an icon font with services like Icomoon. I would suggest to go with vector icons (SVG) if possible, because vectors are resolution independent so you won’t have to worry how they display on high definition screens — they will be sharp.

There are a lot of premium icon packs with a variety of icon styles, so if you need diversity that is also a viable option. Unless you did an icon inventory from the start and know exactly what icons you’ll use in the project, leave room for the option to easily add new icons.

Utilize Style Guides to Keep Your Website Design in Check

Even if we design in the browser, with dozens of templates and components we might lose track of where something is used and in what fashion. That’s why I suggest to build a style guide of all components as a central repository. Specific page templates will be built from this style guide by combining components and modules into whole pages. Components might be form elements, pagination, product listing, image gallery, modal windows, etc. and are used as building blocks for required templates. Keeping everything in one place is really handy when you want to test a specific component.

website design and designing websites

I would suggest to separate styling of these components into separate files. For example, pagination styling will be in in _pagination.scss, form elements in _form.scss, and all these files will be included into a single SCSS file with other files (variables, mixin, etc.). Although your style.scss might be composed of dozens of “small files”, I hope you’ll agree with me that it’s easier to keep track of changes (whether you are using source control or not) when several people are working on the same project if everything is separated into smaller chunks. It’s important that you maintain your style guide even after project is in production, since you need to be able to keep track of every component on the site — no exceptions.

From the development standpoint, there are many approaches to writing modular CSS. Most known are SMACSS, BEM, and OOCSS — I encourage you to read about these techniques because there is a lot to learn, even if you end up developing your own approach. By now you should have a nice collection of components and pages which will enable you to easily build new pages or scenarios. Just copy and paste (or include, if you are using a build system) elements from the style guide and rearrange them as needed. Since everything is modular, you don’t have to worry about design and code consistency; but don’t forget that if you change something semantically, you’ll need to update the style guide with changes (or a new component). To keep everything organized, I suggest you use some sort of templating approach to building pages such as a Gulp/Grunt build system or even good old PHP might do the trick.

What’s Next?

Now you have a central repository of components, pages build from those components, and every piece documented — from colors, icons, and fonts to components that are used on your project. Here comes the fun part. From this point on, you probably won’t open your design tool, and most of the “design” will be done directly in the code. You are not sure how a specific change will impact different use–cases? Preview your design simultaneously on different devices and browsers to see how that heading or button change will impact the design. Not sure about how font additional weights will impact performance if you are including custom fonts? You can test your work–in–progress project performance using services like WebPageTest, and make informed decisions on actual results. You can’t do that in Photoshop or Sketch. That’s why I would choose HTML and CSS over these apps every time when it comes to refinement and adjustments of the original design mockup.

If you really care about design, you should make sure that every part of it is perfect. Something can look amazing in a static design mockup, but it might look terrible when implemented. Let’s test and fix these use–cases in the environment where everyone will see and use them — in the browser.

About the author

Lucijan Blagonic, Croatia
member since September 28, 2015
Lucijan has 10+ years of experience working on the web, including planning, prototyping, designing, and coding standards–compliant and semantic websites and interfaces. He is a strong advocate of responsive design, building mobile–first interfaces where loading speed and optimization are a top priority so that users can benefit most from the website. [click to continue...]
Hiring? Meet the Top 10 Freelance UX Designers for Hire in December 2016

Comments

Bojan Janjanin
A great read, Lucijan, thanks for sharing. This is a similar process to the one I use and have learnt is quite efficient.
Ivo Lukač
Very nice insights in the web creation process. But there are still some parts to improve. What if you could create wireframes and prototypes directly in a CMS instead of using Balsamiq or similar tools? ;)
Lucijan Blagonić
I'd still say it's definitely faster with paper and pencil. :) On the other note, when working on larger projects where the code is often implemented on a custom backend so doing prototypes from "modules" is as good as it gets in that case. Like I said in the article though, I choose my approach based on the project and if the implementation into backend can begin during prototyping/discovery phase — we'll probably take advantage of that as well.
Lucijan Blagonić
Like Ivo said, even this process can be improved upon further but the more we work in code the faster and more efficient we are — that's what I love the most. Thanks.
Ivo Lukač
Starting with paper and pencil, yes. But as soon as you want to proceed switching to a CMS capable of building layouts and block in an easy way would be even more efficient IMO. Then it is possible to do design, content and code work in parallel.... Hope to show you what I mean one day soon ;)
Lucijan Blagonić
I agree with you on that point, especially if you are using a CMS with that capability, but keep in mind that you still need to create a modular design that will be fitted into these building blocks. Looking forward to your example :)
Ivo Lukač
Of course, it needs to be flexible enough. It is not a simple problem to crack :)
Jitendra Vyas
I also like to work with this approach only these days.
Frank McClung
I've been using this approach for several years in web design. It is very efficient and works great if you have a client that appreciates your expertise to the point they trust your design solutions. If you have clients that are new to web design, don't trust you, or have multiple levels of design approval to jump through, then this method won't work well for you or the client.
Lucijan Blagonić
Agreed. This process doesn't work in all cases, but a lot of times it's up to the designer to communicate benefits of different approaches and to make the clients understand. As long the clients have the user needs at the top of the list, I don't mind whatever approach they choose, but that's the story for another article. ;)
Bianca Sherawat
We are also providing magento websites so if you have any query related to magento or you want to develop the website in magento just contact us. You can get answers for your relevant queries, call us on our company number 01724608777.
comments powered by Disqus
Subscribe
Free email updates
Get the latest content first.
No spam. Just great engineering and design posts.
Free email updates
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Lucijan Blagonic
Designer
Lucijan has 10+ years of experience working on the web, including planning, prototyping, designing, and coding standards–compliant and semantic websites and interfaces. He is a strong advocate of responsive design, building mobile–first interfaces where loading speed and optimization are a top priority so that users can benefit most from the website.