Designing in the browser
For the longest time that I can remember, I've been directly designing in the browser. That's right, no Figma, no Sketch, no nothing. Not even a pen and paper. I go completely raw and in the weeds of inspector tools.
Okay, maybe that's a little hyperbolic - even for me.
Dev Tools
What I really meant to say was, it's not that I never sit within a design tool, but the most complete way of visualising something for me is to get a live prototype of an idea working. Whether this is a new feature branch or sitting in tools like CodePen, the browser gives you instant feedback.
Before we get started, I should note, that this isn't a be all and end all. It's a method for designing smaller features or prototyping high level ideas quickly. It also largely applies to working in a smaller teams where process might not be a road block.
At the end of it, design and create how you feel comfortable. These are just a few reasons why I love designing in the browser.
Let's begin
First and foremost, designing in the browser offers you two things:
- Speed
- Sustainability
Speed is quite obvious as you are effectively speeding up the build and testing process. It's live and direct!
However, what do we mean by sustainability? Well, typically in a small team or a well organised organisation, you'll perhaps have a set of pre-built components. These could be React components or HTML partials that you can already use. Being able to use pre-existing components when ideating flows or features gives it that extra feel of realism.
Sometimes, you may already have a work app you're designing. Working on a feature branch lets your play with real data as well - depending on your setup. Most apps may have a dummy database with realistic information that you can already use to visualise.
Although in the past years tools like Figma have plenty of plugins to help you pre-populate realisitic data, it's still not quite the same as seeing close to real (or in some cases real) data within your design experiments.
Code as a visualisation tool
Some might say it's a little bit of a tricky way to go about solving problems. Of course, code can't solve everything - sometimes for larger features, you definitely need to spend time planning, researching, sketching and so on.
However, what coding in the browser enables you to do is to get a sense of how multiple options could work. Your time is finite in smaller teams, so being able to visualise how a potential filter bar could look and feel helps you land close to the right solution.
What do we glean out of visualising in the browser though? Well a few things:
- Cross browser compatibility.
- Accessibility.
- Responsiveness.
- Performance.
- Unseen edge cases.
That last one of "unseen edge cases" is a big one. A problem I've always had while using something like doodling in a notepad, Sketch or Figma is the fact that you may not necessarily see hidden behaviours and be able to account for them.
Countelss times, while tinkering in code as a way of visualising, I've come across edge cases that could have a visual impact. A lot of the time there could also be usage impacts, elements clashing, information not quite flowing right and so on.
That is where, in my opinion design tools constrain how you think about the web.
The chassis and the engine
One analogy I often gravitate toward when trying to describe to peers why the idea of building within the browser is so powerful, is the idea of engineers working on a car. It may be bit of a misnomer this comparison, but we'll roll with it.
If you're an engineer designing a lovely new car, perhaps while designing the chassis, you might want to understand how the engine looks, behaves and fits within the overall picture. In this case, you can imagine the chassis as your visual design and the engine as the code that supports it.
You would hope the folks sitting in CAD tools designing parts of a car understand how engines and their various inputs and outputs work or sit within the overall picture of the cars chassis. This is exactly how I view being able to code your ideas.
Conclusions
Of course, there are no be all and end alls in creative problem solving. Ultimately as a designer or front end engineer, that's your goal. Solve visual and creative problems in a way that makes sense. As long as you are communicating your ideas and solutions in a well thoughtout way, your tools shouldn't matter too much.
For most though, design tools may work just fine, but for mysef personally being in the knitty gritty of code is where I start to understand the constraints of my creative output. Some might say that has it's drawbacks too, perhaps it can curb creativity a little, but sometimes, even the littlest piece of code helps inspire me in solving visual problems and building great products.
I may come back to this article at some point to update it. There's a lot more thoughts that I haven't quite been able to verbalise regarding this topic.
To be continued.