Prototyping & Designing in the Browser

Photo by Hal Gatewood on Unsplash

In my opinion, ensuring that the user experience of your website or app is usable and accessible, should be the first thing any designer or developer should consider. Having a pretty website or app is great, but is it actually usable? Pretty doesn’t necessarily mean easy to use or easy understand. One thing that designers sometimes fail to consider when designing a new UI/UX, is the medium or device that their users are using. Mobile has been the most prevalent device used on the web in recent years. With the rapid rise in mobile users on the web, a Mobile-first approach to design is a must (in most cases).The browser is also of equal importance for consideration, but some designers can forget that the product they are designing will actually be used in a web browser.

Before even thinking about the actual UI, I believe that designers should create low fidelity prototypes to ensure that the usability of a product has been thoroughly thought out. This allows designers to validate any ideas they have or any assumptions they may make. I think it’s important to enable everyone (mostly designers and developers) to create simple prototypes, as it opens up the opportunity to take great ideas and make them into something more tangible that can be shared with your peers. Gmail and Google assistant came from prototyping an idea in Google’s famous 20% time.

So I set out to make this a reality at my current place of work, Zuto. I first created a React prototyping tool, which surely enough, allowed developers to quickly create prototypes in React (or try React out as some Devs had not used it before) and not have to worry about the setting up of the project. I did this by linking our style guide’s stylesheet up to it and dealing with things like Webpack configuration, so that the Dev that wants to just prototype, doesn’t have to worry about setting these things up. It’s simply: Clone the repository, then npm i & npm start .

The massive advantage of having a tool like this for developers to play with, is that anyone who is savvy with code and either knows React, or wants to learn React — can do so very quickly and easily. They don’t have to worry about writing styles, setting up build steps or setting up React it’s self. They can just get on with the coding.

However, in order to achieve my goal of being able to “enable everyone (mostly designers and developers) to create simple prototypes”, I set out to create a tool for my other colleagues who do not know how to write a single line of code. Just because they don’t know how to code, doesn’t mean they cannot come up with great ideas and solutions to problems, then prototype those ideas. So why not build a tool, that allows them to create a prototype of their proposed solutions, so they have a working example to present to any possible stakeholders…

Other than to give my colleagues another avenue to show off their ideas, my main reason for wanting to create this tool, was to allow our Designers to ‘design in the browser’ once they have established the usability of their low fidelity wireframes. In my opinion, designing in the browser is very important (I’ll get onto why) and it can be done by writing very little code, given the prototyping tool that was created is good enough… My prototyping tool is still in it’s infancy and still needs lots of work. However, the tool itself was a prototype of my own, so I hope to improve as I go on!


So why should we design in the browser I hear you ask… before I explain, I want to point out that I’m in no way saying that we should skip the part where designers jot down ideas and stop make low or high fidelity designs for solving problems all together. I simply believe that designers shouldn’t waste time creating pixel perfect designs in photoshop or sketch (simple paper sketches are great however as they are quick) and they should use prototyping tools to create high fidelity designs in the browser. An example of a tool that you could try to get your colleagues to use while you are in the process of building your own brand specific tool, is right under your nose. Enter built in browser developer tools (dev tools as I will refer to them from now on). As developers we probably use these on a daily basis (if you are building a front facing product). They are really simple and easy to use, they are actually manipulating the page in the browser, and they allow you to manipulate the markup and styles in almost anyway you like. However, the downfall to dev tools is that your changes are not saved (I am aware Chrome has a relatively new feature that allows you to save your ‘dev tool’ changes to your local machine, but this isn’t a great solution). So while dev tools are a great start to getting your colleagues building prototypes or manipulating designs in the browsers; building your own tool is the way forward in my opinion.

Having your own prototyping tool, that allows non-code savvy users to create prototypes that can be viewed in the browser, means that with help from a developer, those prototypes can also be put into GitHub. Once in GitHub they can be collaborated on and eventually implemented fully if the prototype is favourable.

Enabling people to prototype locally on their machines is one thing, but enabling them to host their prototypes online to show off to stakeholders is another. With the help from a developer, a prototype could be hosted online to be viewed and tested on any device, in any browser. The massive advantage of this is that you actually get to shape and build your prototype to fit and work in actual browsers and real devices, rather than trying to get them to look good in sketch or photoshop. So that’s argument 1. for designing in the browser — you see how it actually works in the medium you are designing for. Don’t just design in Sketch, because your users don’t use Sketch to navigate your website. Design in the browser; then you will see exactly what your users will see.

Argument 2. for designing in the browser, is that the prototype is the one source of truth. There can be no pixel pushing, there can be no argument over colour, and there can be no discrepancy between design and build, because there is no design to refer to. Only what is built and collaborated on, in the browser.

Which brings me onto Argument 3. for designing in the browser. Prototyping, or designing in the browser, encourages and enables easier collaboration between Designer & Developer. If you are talking about the colours and layout of a component for example, but you are showing how it interacts with the browsers; both Designer and Developer are now speaking the same language. Developers know browsers and code, Designers know designs and user experiences. Merge the two and you have a common ground. Blur the line between Designer and Developer, and end the common occurrence of “throwing designs over the fence”. This way, collaboration becomes much easier and more common.

The fourth and final argument I am going to make for designing in the browser, is kind of a double header… mainly cause I want to wrap this post up now as I feel like it’s getting too long! Designing in the browsers will increase the speed of delivery of your product and maybe even the quality of your product. If we encourage more ideas to be made into prototypes, then more ideas will surface and be made into actual viable tickets to implement and hopefully, the product will be improved — not just implemented on incrementally (BAU tasks). Furthermore, if we remove the design process of Problem, Initial design, Sign Off, High Fidelity Design, Build, Reiterate, Build again etc. and we change to a more streamlined approach of simply finding a problem to solve, then designers and developers work together to come up with a useable, working MVP version of a solution, using a prototyping tool, we can get to testing it on actual users and gathering data much much quicker. We reduce the blockers such as pixel pushing and we get to the MVP much quicker.


On a side note, once you have built your prototyping tool, it would be a good idea to write a simple tutorial on how to use it and maybe even the benefits of using it… feel free to send people to this article! :)

Anyway, hopefully this was useful and encouraged even one person to try and prototype more!