Ephemeral artifacts
When your designs are the thing itself, you don’t need the blueprint
Ever had an idea you can’t remember? You know it was brilliant, but it’s gone. And if you can’t remember it, maybe it wasn’t that great after all.
As a hybrid designer/developer, I start most of my design work in the browser. The first action I take isn’t pencil to paper, it’s fingers to keyboard:
- HTML: Describe the UI, write the copy
- CSS: Structure the onscreen information
- JavaScript: Implement behaviour
- Meteor or equivalent: Model and persist data
This is the fastest way I’ve found to work. It’s faster than mocking screens in Sketch. It’s faster than jotting down notes and sketching ideas in marker. With Sketch or other UI design tools, I get distracted by all the shinies: the alignment options, font-sizes, gradient pickers. I start focusing on using the tool rather than making the thing. If I’m sketching on paper, I quickly start finding the lack of an “undo” option, copy/paste, or layers preventing me from expressing my idea. I feel an urge to skip intermediary steps and go straight to designing with code. This way, I only have to do the work once: in the browser. If I use a design tool, now I’m doing it in the design tool and then again in the browser. That feels redundant.
But it isn’t always redundant. A downside of this way of working is that you don’t leave a conventional paper trail showcasing your thought process. After all, a big part of design is communicating with others. The best way to collaborate is to pull ideas out of people’s heads and get them into a format that you can have a conversation about. No one designs something alone, but in collaboration with other designers, developers and stakeholders.
I love doing that in design brainstorms. Group whiteboarding, jotting down ideas on post-it notes and organising them, wireframing, and even sketching work well in group form to collaboratively generate a bunch of documents that represent a sense of the design. These are ephemeral artifacts. Short-lived. Fleeting. Temporary. They hold value during and just after the meeting, until their half-life is up, and they earn the right to evaporate and pass into our memories.
Some people take pictures of everything and carefully file it away in their archives. But other than recording the ideas that will be immediately useful to make progress with the design, I prefer to forget. Weeks down the road, you won’t need that brilliant idea someone threw up on the whiteboard in a meeting. Even if people remember it as brilliant, the design will have evolved past that.
I find it more compelling to record my thought process in version control. Each commit is a part of a larger thought. I try to tag commits that represent a meaningful evolution. You can step back a few tags to see how the design evolved. It works well, though I’d love to see design tools embrace this and provide views of a repository that support design meetings and make things more understandable for non-technical people.
When you design in code, you embrace the tools of the developer. Version control incentivises you to iterate quickly, applying minimal changes. You develop a mentality of moving forward quickly and not looking back — while simultaneously recording everything for posterity and empowering you to branch off in different directions if you want. Each step is transitory: it recedes into the past once you commit and move on. Critically, though, each decision you make contributes materially towards the final product.
It’s not wasteful, because you’re using each decision to reach a new one.
There are no artifacts on record, just the evolving design. It feels pure and clean, almost like a stream of consciousness.
Ephemeral artifacts are a waste. If only we were all telepaths, we wouldn’t need them at all.
