I did a series of posts a while back about rapid prototyping (as relates to the career of a UX Designer, obvi) and found myself extolling the virtues of good ol’ HTML and CSS as, yes, great rapid prototyping tools. They’re fast, they’re easy, and they just work…across all devices and viewports sizes, a big bonus when it comes to baking in basic web responsiveness.
Lo and behold, I had the chance to match my walk to my talk with a client last year…and it went quite well from a design point-of-view, validating my old-school love of the approach. So, I figured I should share the story in hopes of bringing more UXers into the HTML/CSS prototyping fold.
I will admit, one of my feet does currently rent out space in the Figma camp — it is an amazing tool, and it just seems to keep getting better and more powerful. But this client is relatively small, and housed most of its design tasks within its tiny Marketing team, which didn’t warrant the use or expense of such technical tools as Figma or the Adobe Creative Suite. (What work they didn’t outsource was done mainly in Canva, and I suspect that isn’t uncommon within small business circles these days.)
Had I done my wireframes and prototypes for their project in Figma, I would have been handing them deliverables they couldn’t do much with in the long term, plus saddling them with a not-insubstantial learning curve should they decide to maintain them moving forward.
That’s when my inner nerd voice whispered, “Just build it all in HTML…you know you want to!” And I’m just crazy enough to listen to that voice every once in a while.
Now, as I spoke of in my earlier post, HTML is the easy part. Markup language — the ML of HTML — is not programming, it’s simply marking up (duh!) content in a way that browsers can digest.
Technical aside #1: There is a language called markdown which is intended to be an even faster, lighter way to write HTML, and there is a lot of support for it across many web tools. I won’t go into it more here, but just know that if angle brackets aren’t your vibe, you might want to check out markdown.
However, CSS is where the real power lies, especially as regards responsiveness — how well that content will display with various viewport sizes and resolutions.
To the search engines! In the lush, extensive forest of CSS libraries, surely there was a clean, simple candidate which would provide all the basics I needed while still clearing the way to add in custom styles as I went forward. (Uhh, and, hopefully, something that didn’t rhyme with Hootflap.)
Technical aside #2: I have nothing against Bootstrap. Some of my best friends use Bootstrap. I had a gig where all I did was customize a Bootstrap implementation. I just wanted to see what else was out there, that’s all.
Enter Bulma. As a free tool which landed consistently in online top 10 lists, it immediately caught my eye. After checking out its documentation, it looked promising enough to give a go. If I found that it wasn’t working for me, I could always try something else—that’s how wireframing rolls: fast, dirty, low-fidelity.
Needless to say, I found it a pleasure to use. It provided just enough structure to create robust, responsive-friendly pages quickly and easily, but also had the ability to grow into something more substantial as the website began to take shape.
Technical aside #3 I also found a tool called Realtime Colors which was great for testing out color and font combos in a way that stakeholders could easily understand and appreciate. The creator has a YouTube channel under the handle Juxtopposed — definitely worth your attention!
Bulma takes advantage of Sass, a CSS preprocessor which provides even more control, especially when it comes to color usage. By dropping in a temporary color palette of black, white, and intermediate grays, I was able to create fast iterations of ‘wireframes’ in HTML. (Basically, extremely rapid prototypes!)
Sass is a powerful addition to CSS and, like markdown, has widespread adoption and support. What drew me to it initially, many years ago, was its ability to create variables within your CSS that can be referenced more easily than HEX or RGB color notation. For example, say you are working with a particular branded shade of blue for a client. You can enter the color notation once and label it “ClientBlue” within your Sass. Anytime you need to drop in that color for an element — a font, a border, a background, whatevs, you can confidently call “ClientBlue” and know that you are using the proper shade. Plus, the technical color notation is stored in one place, rather than sprinkled throughout your Sass file. Should that shade of blue change later, you can update the color notation for ClientBlue once and it will cascade to every use of that variable throughout the website.
Bulma basically met every need I had with this particular client project. These rapid HTML prototypes fulfilled all the functions of wireframes and grew seamlessly into full-blown mock-ups. They were used to spark ideas among my build team, to get sign-off from stakeholders, and for evaluation by interested third parties.
But the best part of this approach is that — once a design has been chosen — it already exists in HTML/CSS. My dev team was able to lift whole chunks of my markup to use in their working builds. I want to stress this point, because I was especially sensitive to this and sought out confirmation from the developers as we went along. I didn’t want my own bias to color what was ultimately right for the project team. I was reassured each time that I was saving the devs time and effort by having these responsive building blocks ready to be cut-and-pasted into their code. And the deliverables to the client were honest-to-goodness web pages that they could call up on their own computers, phones, and tablets. No special software or technical knowledge needed, just their preferred web browser.
====
I like using HTML and CSS to build iterations of web elements, that is probably clear by now. I like seeing the thing I’m creating in the actual context it will live in. It eases worries about lots of things for me: responsiveness, color translation, page structure, etc. And, as I have said before, HTML is easy to work with. It’s not coding, it’s markup.
And my encouragement to learn these tools and use them for your own web projects remains unwavering. To my mind, there will always be two kinds of folks: those who prefer highly customized, artfully created pieces of furniture, and those who are happy with IKEA. There is a subtle, but important, difference in the way one learns about frontend web design and development when one builds it from scratch. While time savings can be seductive in the short term, I believe there are long term costs whose value is often overlooked.
But I recognize that the push towards automation of web development is fully underway. AI and LLMs are rapidly getting to the point where they can spit out these elements as fast, if not faster, than I can. And while I’m no Luddite, I do still see the value of a human aesthetic when making some of these decisions. Not every web element on a given page needs “hand crafting”...but the larger, more complex those assemblages become, the more they need empathetic, human oversight.
Because “time = money” is a foundational tenet for most business people, and bottomline considerations rule the day when business decisions are made, I worry that the pressure to use these automated tools will be too great to resist, and that the rush toward smaller costs and greater profits will settle the issue before voices like mine can be heard or considered. I’m not saying that a humanist perspective will always win out, just that it should continue to be a part of our deliberations, lest it become eliminated altogether by super speedy algorithms.
Until I come across a tool that can do it faster and better (and which meets my personal standard for aesthetic sensitivity), I will continue to use HTML and CSS to quickly iterate through ideas for web-based projects — and have lots of fun doing it!