Is it ever a good idea to design in the browser?

Designing for the web is often a long process. First, you have to establish the goals of your site, the potential users, the theme, and the content you want to display, and you haven't even started creating the designs yet.

Then you dive into each webpage and work out how the content you have will fit on a screen, where to draw attention, and how to get the user to click the button which gets them to buy your product (or whichever type of conversion you are going for).

Nothing is that easy. Something will always go wrong.

You finally start building, but things don't work as expected, get missed, or are just impossible because they work on paper but not in code. It isn't anybody's fault, but it happens and is frustrating.

Why are there inconsistencies between design and code?

Designers often have little idea how a website is built. It's your job to bridge that gap, but doing so after the design has been completed is difficult

Designers make mistakes. They don't know web technologies inside-out. They only remember issues they've run into before, but they aren't at fault for this. Nobody is, but there will always be some amends to make.

Designing in the browser

To fix some of these problems, you might take the approach of designing in the browser. You skip the design step (or most of it) and create the site based on wireframes. You would work much more collaboratively with your designer and start adding in customisations after the wireframes are complete.

Think of it like pair programming, but with a designer.

It's faster to implement as a large part of the process is cut out, and prevents you from having to deliver (or backtrack) on promises which can't work in code. The collaborative approach also means you can quickly make changes to things which don't work or look right, instead of waiting for a response (or forgetting about them). Feedback is immediate.

The downside is that it's harder to change once built. Designing in a program like Sketch or XD is faster than writing up code, and when you're handing over a flat design, there's no expectation that the user can navigate around or that things will be functional. On the other hand, clients will often expect a website to be fully functional upon viewing it, even if it's only in the design phase.

Using traditional design

Traditional design methods are still a great approach to take. They're more flexible and more suitable for nailing down precisely what the client without the complexity of coding the site as well. It's easier to make significant changes as none of the functionality is affected at the design phase, which causes drastic changes to be less costly too.

The traditional approach also gives you a definitive end goal, where you know what you have to achieve before you even start building. That can be very reassuring, especially for more junior developers.

On the other hand, that also means the developer has less creative freedom. It's much harder to suggest design changes after the designs are finished and sometimes that makes it harder to be flexible, especially if the client has already seen it.

What should I use?

As always, you should use the approach which is best for you. In most business scenarios, this will probably be traditional design methods. Still, if you're a freelancer or you're working on a personal project, you could see benefits from designing directly in the browser.

Designing in the browser is an excellent approach for developing side projects.

If you're creating a site for yourself, or somebody you know well, then it can save you time and energy. It also means that you don't get blocked as a developer by not knowing how to use a design tool.

Choose the approach which is best for you. Both can be good, and both can be harmful. You need to have a good understanding of your client's needs and maybe most importantly, know how well they understand the development process.