So then the question becomes: how do you most effectively communicate designs, to facilitate the best discussions about those designs? My answer is: lots of little prototypes built with HTML, CSS, and JavaScript.
I really enjoyed this deep dive into some design fiction work done by Fabien Girardin, Simone Rebaudengo, and Fred Scharmen.
(Remember when Simone spoke at dConstruct about toasters? That was great!)
I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
A stylesheet to imitate paper—perfect for low-fidelity prototypes that you want to test.
It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.
What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck:
At the point of preparing for usability testing, it seemed ludicrous to move to any prototyping material other than the one we were already building in. The bedrock of the web: HTML, CSS and Javascript.
If you employ a hack, don’t be so ashamed. Don’t be too proud, either. Above all, don’t be lazy—be certain and deliberate about why you’re using a hack.
I agree that hacks for prototyping are a-okay:
When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.
I’m not so sure about production code though.
The latest episode of the Clearleft podcast is live and it’s all about prototyping.
There’s a bit of a narrative thread in there about airplanes, kicked off by a great story Benjamin tells about testing a physical prototype …of the inside of a transatlantic airliner. Lorenzo recounts his story of mocking up a fake CMS with readily-available tools. And Trys tells of a progressive web app he whipped up for our friends at Suffolk Libraries. There’s even a bit about Hack Farm in there too.
But just to make sure it isn’t too much of a Clearleft love-in, I also interviewed an outside expert: Adekunle Oduye. It was very kind of him to give up his time, especially considering he had just moved house …in a pandemic!
There are some great words of wisdom, immortalised in the transcript:
Prototypical code isn’t production code. It’s quick and it’s often a little bit dirty and it’s not really fit for purpose in that final deliverable. But it’s also there to be inspiring and to gather a team and show that something is possible.
—Trys
If you’re building something and you’re not really sure if it’s a right solution, use the word prototype versus design, because I feel like when people say design, that’s like the end result.
—Adekunle
I always think of a prototype as a prop. It’s something to look at, something to prod. And ideally you’re trying to work out what works and what doesn’t.
— Benjamin
The whole episode is just over 21 minutes long. Have a listen and enjoy the stories.
If you like what you hear, please spread the word. Tell your Slack colleagues, your Twitter friends, your LinkedIn acquaintances. And if you’re not already subscribed, you can remedy that on Apple Podcasts, Google Podcasts, Spotify, Overcast and anywhere that accepts RSS.
I’m usually building one of three things: a demo, a prototype, or a minimum viable product (MVP).
I’ve seen some confusion over these terms — some people seem to use them somewhat interchangeable. But they’re not the same thing, and building one when you need another can cause problems.
This is a very useful distinction!
Good tips on prototyping using the very materials that the final product will be built in—HTML, CSS, and JavaScript.
The only thing I would add is that, in my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.
Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.
I’ve thought often of how our design and prototyping tools for the web are often not of the web. Tools like Photoshop and Sketch and Invision create approximations but need to walk the line between being a tool to build native apps and to build web apps. They do well in their ability to quickly validate designs but do little to validate technical approach.
A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.
A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.
Ethan’s been thinking about the trends he’s noticed in the work he’s doing:
On that last point…
The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.
That’s why I’ve realized just how much I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it’ll change if, say, fonts aren’t available, or JavaScript doesn’t work, or if someone doesn’t see the design as you and I might, and is having the page read aloud to them.
Cennydd enumerates what design sprints are good for:
And also what they’re not so good for:
A series of quick’n’dirty prototypes to illustrate some of the design challenges involved in handling personal data:
If we don’t start exploring what the General Data Protection Regulation means for people, the same thing that happened with the cookie law will happen again.
These new rights have the potential to improve how our digital products and services work.
This is a clever quick’n’dirty way of prototyping iterations on an existing site using dev tools and screenshots.
If you’re intrigued by the kind of design sprints I wrote about recently, here’s a handy collection of resources to get you going.
- Pre-sprint
- Understand: Gather existing knowledge, expose assumptions and unknowns
- Diverge: Illuminating all possible paths
- Converge: Choose the right path
- Prototype: Quickly build the right path
- Test & Learn: Test the right path
A really terrific piece about wireframing for responsive designs. Again, it’s all about the prototypes.
Mark has put together this rather excellent prototyping tool. It’s basically the V from an MVC system. You can easily move stuff around, change data …all the good stuff you want to do quickly and easily when you’re prototyping in the browser.
A browser-based tool for creating HTML prototypes.
Pictures of some prototypes of the clock of the Long Now.