This article was first written on my blog. You can find the original post here: https://danspratling.com/2020-03-02-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).

Then, after all that, you finally start building. Any developer could tell you, even after all this planning, things still go wrong. 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?

Often designers aren't developers and don't have any insight into how programmers create things or what limits us. They learn from their experiences, as do we, but are picking up knowledge second hand. They design in grids, but probably don't know the nuances of CSS Grid. They aren't at fault for this, but it does mean there's always going to be some creative control given to the developer to try to match the designs as best as they can.

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 a pair programming approach but with a creative instead.

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.

Which 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.

--

If you enjoyed my article, please leave a like or a comment. You can follow me on twitter to keep up to date with my latest posts & discussion within the development community.