Give your team a wide field to play in (design with HTML & CSS instead of wireframes)
Some lessons from designing (and redesigning) the same website over 15 years
I’m going to throw my standard disclaimer up here. I’m saying this as much for myself as for you, the reader. I find I keep making the same mistakes over and over, running into the same dead-ends. As much as this is to help someone else, I also learn best through the act of actually writing this stuff down.
We are now on version 7 (I think, anyway, it’s around there) of the Longworth Dental website. Our first versions ran on WordPress. Then briefly Squarespace. Then I tried outsourcing to a development firm (it didn’t go well). After I’d had enough, I accepted that I should probably learn how to code this stuff myself.
Version 7 is a version that I’m really happy with. I did the wireframing and started the code, and the talented Ben Mendis made it all a reality. We decided on a React stack, based on two TailwindUI templates, and hosted on Vercel.
I designed the site originally in Balsamiq. As far as wireframing tools go, it’s my favourite. The pricing is reasonable, and I like the idea of working with low-fidelity mock-ups to get started. It puts the text front-and-centre, it just works the way my brain works.
But we started to run into trouble with wireframing. Sometimes we would be working on the site, and we’d realize that a change needed to be made. We made the change, no big deal. But after two or three times, the wireframe design would be just out-of-sync enough to be annoying: it would have mostly good stuff, but then in places would still reflect the old design. With a two-person team, it was still fine, it was just annoying. I didn’t want to spend time updating the design to reflect the reality.
Without too much ado, here’s the design gallery. The big long rectangles are the page itself, the post-its are the notes we made as we went, and the screenshots on the side are images or examples of what the finished result should look like. This really is low-fidelity: it’s not meant to give the developer anything close to a pixel-perfect sense of what the final result will look like. But it does give all the sections and some of the code and logic.





The problem with this is that there is so much wasted work. It took a long time to design these. And at this point, they are hopelessly outdated. It’s true of the entire site at this point: the project is close to being done, but in order to add in back-end functionality, we’d need to buy into Vercel’s paid tier, and start adding a bunch of marketplace add-ins that just don’t make sense to pay premium rates for. Like databases. Case in point: we have a single video on the site (for now), and it costs us around $2/month to serve that video through AWS. It’s sort of ridiculous, and it makes me not want to add any other videos to the site, which is also sort of ridiculous.
The goal here is to give people a wide area they can play in, where they can start to have fun with this stuff and not worry too much about cost spikes. This is true for the technology we use, as well as for the people we work with. Keeping them “under control” doesn’t work. Giving them room to play does.
Even though you try to put people under some control, it is impossible. You cannot do it. The best way to control people is to encourage them to be mischievous. Then they will be in control in its wider sense. To give your sheep or cow a large, spacious meadow is the way to control him. So it is with people: first let them do what they want, and watch them. This is the best policy. To ignore them is not good; that is the worst policy. The second worst is trying to control them. The best one is to watch them, just to watch them, without trying to control them.
—SHUNRYU SUZUKI ROSHI, Zen Mind, Beginner’s Mind (as quoted at the top of Chapter 21 of Gabor Maté’s Scattered Minds)
I’m not sure I agree with comparing people to cows or sheep here. I’m deep in the middle of raising 3 kids right now. I can tell you, the best way to control them is to give them a big field to play in and then tell them to be mischivious. And then watch them so they don’t hurt themselves along the way. That way, they learn what works and what doesn’t work without us having to direct them. It’s true that we need to make sure there is no risk of large injury in the field we choose, but I think that actually makes the analogy better. When we are running a team or a business, we have the same responsibility: “play as much as you want over here, but stay away from that one thing, it’ll bite you”.
I’m gonna throw a gallery of the current version of the website here now, because it’s going to change again soon. I’m coding version 8 in Ruby on Rails. I like the premise that we can code all of this ourselves, handle the tech ourselves, and get good performance for a fraction of what we get with the big providers.





On that point, I’m not wireframing this time. It’s true that it helps that I already have an existing site that I can use as a reference when needed. But I’m also changing a lot of the design: there really isn’t that much of the CSS that I’m bringing over. And this time, I’m designing in HTML and CSS. I start with the main elements, I drop them in the right spots, and I make sure that I’m designing for mobile, laptop and desktop sizes at the same time. I’m not coding logic right now (well, as little as possible), and it’s allowing me to move relatively quickly.
The best part is that I’m not spending dozens of hours drawing a plan of what the site will look like or could potentially do. Instead, the code that I’m putting in will actually be useful later, it won’t be wasted work. When it comes time to “develop” the site, it’s already going to have everything done.
It’ll be like a stream that we need to build into a river, not like a picture of a river that we need to turn into a river.