This is just terrific. -- Old man shouting at clouds... I learned how to do low-fidelity paper prototyping from Luke Hohmann at OOPSLA 1998 in Vancouver. htt

This is just terrific. -- Old man shouting at clouds... I learned how to do low-fidelity paper prototyping from Luke Hohmann at OOPSLA 1998 in Vancouver. https://www.goodreads.com/book/show/2017112.Oopsla_98 https://www.goodreads.com/book/show/2017112.Oopsla_98 Just like this: "Lo-fi Paper Prototype Example" https://www.youtube.com/watch?v=TRlcZJpl0dw https://www.youtube.com/watch?v=TRlcZJpl0dw I can't quickly find Luke's paper online. IIRC, this book is pretty terrific: "Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces" [2004] https://www.sciencedirect.com/book/9781558608702/paper-prototyping https://www.sciencedirect.com/book/9781558608702/paper-proto... Here's the thing. I have near religious devotion to lo-fi prototyping. I really thought it'd become the norm. Back then, I envisioned UIs would be developed like: All the requirements gathering and analysis. User profiles, use cases, creative writing, story boards. Then convert story boards into paper prototypes. Then validate paper prototypes with users. Usability testing where the devs pretend to be the computer. Iterate. Then convert paper prototypes into code mockups. More usability testing. Iterate. Then convert mockups into an app. For this to work, be practical, the cost of change has to be dramatically reduced. To do that, there needs to be a workflow that connects paper to mockups to app. In my future perfect world, TinyUX (Balsamiq, Figma, etc) must first ingest paper prototypes and generate code. Something declarative, like SwingUI. Just enough meat and bones to hand off to devs. Who can then flesh it out or reimplement it.