On design prototyping.
Last month, I visited San Francisco to meet some of my design heroes in person and learn as much from them as I could.
The following paragraphs are notes on things I have learned during my stay in the bay area. All of the observations were made through the lens of a prototyper. I hope they can be helpful to some people.
Background
I am a prototyper, exploring how interfaces can blur between the digital and the physical to create integration of computing into human perception. I do so because I believe that technology should not enslave us by hijacking our evolutionarily grown attention mechanisms, but rather empower us to have the agency we need to build our own realities as we envision them.
You can find recent projects of mine and my contact details on the website in my bio. Feel free to reach out if you have questions about this essay or are interested in working with me.
1. Twitter is (still) a Hive-Mind for the Tech-Industry.
Exposure of work and ideas on Twitter connected me to like-minded individuals in tech in no time. Being courageous and proactive through exposing work will pay-off through forming connections and accelerating learning. If you are a designer/prototyper Twitter can be a powerful tool for feedback, validation and networking.
2. Prototypes as Memes.
When it comes to sharing work on Twitter it is worked best for me to package them in quickly digestible 20–50 second videos with a short catchy but clear description. The video should have a short build up, followed by a climax moment. It turned out as not important to share details about implementation or inspiration.
3. More Clarity. More Impact.
Clarity of communication mirrors the purity of thoughts. The clearer the communication, the more impact it will have. This is true for presentation, conversation and portfolio.
I learned that I need to be clearer on:
- My stance in the spectrum between designer and prototyper.
- My preferences concerning divergent or convergent processes.
- My positioning within the field.
- My personal and career goals.
- My vision for interfaces with technology.
- My opinions on the state of technology.
- My motivations behind my work.
Words might not be the best format for conveying thoughts for everyone. Writing (without LLMs) however is a powerful tool for reaching more clarity as it exposes vague and cloudy thoughts and helps sharpening their underlying idea if consciously practiced. [1]
Ego is the enemy of clarity because it manipulates thoughts in subtle often subconscious ways changing their goal from seeking truth and long-term growth to short-term gratification, defensiveness and comfort.
The price of distraction is time. Distraction delays and inhibits the process of sense-making that is essential to forming clear thoughts.
Ego invested thinking and bad attention hygiene should be avoided at all cost to uncover the truth behind ideas and communicate in clear, easy and understandable words.
4. Prototypes are Products of their Own.
Usually a prototype in professional context is framed as a tool for testing the impact of a feature within a product through making it experienceable.
However a prototype could be also seen as a product of its own with product-thinking directly applied to its creation. Its target-audience (with pain-points, problems and needs) are the people it is presented to. It strives to solve the problem of digging deeper into the meaning of a design idea and then communicate the insights. Every prototype also has a cost attached, namely the time invested to build it. The return-of-investment is a decision made because of it.
Applying product-thinking to prototyping process itself can make it more targeted and efficient, its success measurable and provide data for improvement of future prototypes.
5. Survivorship Bias & Five-Why’s.
Survivorship bias is a logical error in which attention is paid only to those entities that have “survived” a selective filter, which can lead to incorrect conclusions. [2]
While analysing data gathered from usage of products, survivorship bias can lead to misinterpretation leading to wrong decisions on future features and directions.
In prototyping survivorship bias can occur through not putting enough attention on defining the initial problem a prototype should solve. This can lead to a costly waste of time.
A technique for preventing this bias is to use the 5-Whys method. Through 5 iterations of asking “Why?” on the current set of problems requiring prototyping. Once the root problem is uncovered it becomes much easier to formulate ideas that could solve it. [3]
6. Speed, Smarteness & Honesty in Implementation.
Losing oneself in detailed technical implementation of interactions can slow-down the pace of prototyping. [4]
A good question to ask is:
What prototype is the least effort with the biggest impact?
As prototypers act on a spectrum between design and engineering being upfront on the intention and implementation of a prototype from design and engineering perspective helps team-members to understand the problem space it is aimed at solving.
7. Parametric Workflows.
An advantage of functional prototypes is that they are naturally procedural. Variables can be exposed through little additional UIs with sliders, toggles and colour-pickers. This makes the prototype itself a tool for team-mates to express their ideas. Those parametric workflows can be used for divergence and convergence of an idea depending on the stage of the project and the exposed parameters.
8. Room for Craft & Storytelling differentiates Prototypes.
There is a purpose-driven part of the prototyping process and a taste-driven part. While the purpose-driven part revolves around building out functionalities fast to test them, the taste-driven part is the “last mile” of pushing a prototype to feel beautiful and refined.
Time is constrained, which often leads to undervaluation of the taste-driven part in the process as it adds time beyond establishing the framework of interaction. The last 20% of crafting can have big returns though, through giving a touch-and-feel to the prototype that can be defining to its success in presentation. Factoring in time for this process will enable prototypes that ultimately lead to more beautiful interactions in the product feature they lay out.
As mentioned above it is not necessary to technically implement every little detail for efficient storytelling. Sometimes “faking” aspects of a prototype through video-making can be sufficient, after making up one’s mind about what feels right through the building process.
9. Tools of Choice.
The choice of tools influences the outcome of the prototyping process. It is good practice to question tools of choice of implementation for every given prototype:
Do technical choices support the initial goal/idea of a prototype?
Which traits of the prototype arise from the used tools?
Is there another tool that allows to get closer to the exact vision?
Keeping those questions in mind helps to understand if the tool of choice aligns with the initial vision for the prototype, rather than adding friction or diffracting the idea.
10. Coding as a Prototyper.
Coding is more than a tool. It is the sequential thought-process behind building out interactive behaviours. Interaction could be framed as a flow of data between different functional entities.
Prototyping code is different from production code. It is not as constrained by models and rules aimed at ensuring scalability, maintainability and modularity of a codebase as engineering code. It is rather aimed at accelerating and validating thoughts about interactions before engineering hours are invested into implementation.
The advent of LLMs foregrounded the idea that one can build everything they can think off. This conclusion introduces the risk of degrading the thought-process behind coding from a process of sense-making to an act of gambling.
A question that should be constantly asked to gain immunity against this behaviour is:
Do I understand what I build?
11. Learning from Engineers
Even-though prototyping code has different goals then engineering code as defined above. Some practices established by engineers can help making prototypes “snappy” and lean and underlying code useful to form a mental model for implementation:
- Establish rules for what is positioned where in your code.
- Write code that is modular, re-usable, non-redundant and simple.
- Solving a problem is much easier, than finding the simplest solution.
- Using features of IDEs safes time and helps to establish good practices.
- Understanding of concepts like springs, forces, acceleration, deceleration, velocity, tension and inertia can supercharge the motion behaviour of prototypes.
- Writing comments before handing of the code in a review with an engineer, will increase own understanding and learning through prototyping.
12. A Love-Letter to San Francisco.
San Francisco is the place of my dreams since I became interested in prototyping and that was confirmed in many ways during my visit. The culture of people who challenge their ideas through relentlessly building and exposing them to the public creates the highest concentration of intelligence, agency and beauty I have ever witnessed in a single location. I hope that one day I can be a part of this captivating community and re-locate there to contribute on-sight.
Acknowledgements
I want to thank Shengzhi, Martin, Marisa, Jason, Alessio, Greg, John, Rob and all the other people I have met for generously taking time and sharing their thoughts and experiences with me.
Resources & Additional Reading
- [1] Writes & Write-Nots by Paul Graham: https://paulgraham.com/writes.html
- [2] Survivorship Bias on Wikipedia: https://en.wikipedia.org/wiki/Survivorship_bias
- [3] The 5-Why Method on Wikipedia: https://en.wikipedia.org/wiki/Five_whys
- [4] What Do Prototypes Prototype? by Stephanie Houde & Charles Hill: https://hci.stanford.edu/courses/cs247/2012/readings/WhatDoPrototypesPrototype.pdf
