Here’s an experiment. I often wrestle with product ideas in my head, thinking about opportunities to present and apply technology. Instead of keeping them up there, I’m going to try writing them down and put them out there. If I end up making something later, I can come back and revisit this piece to trace it’s evolution.
This is not a startup pitch questionnaire thing. I’ve filled up a lot of those, and while they might be useful for formalizing businesses, the goal here is to capture ideas and what makes them tickle. Perhaps this will turn into an ongoing series – we’ll see.
I’ve been working on this idea in my head for a few years. There has been a few incarnations to it, which I will shortly explain, and there seems to be a version of it that feels viable. Let me explain.
There is this gap between designing and implementing software that feels incredibly poignant right now. Today, you can break down an “idea” into three separate aspects, generalizing of course. There’s the idea itself that is based on data or intuition, and can be formally expressed as a Product Requirement Document that PMs write. Then, there’s a set of screens that are created by a designer, typically in a pixel-based design tool. If they are rigorous about it, it gets built into click through prototypes (state of the art) and validated on the usability end. Then, the engineer pulls both of these artifacts together and build it into a piece of software.
Let me point out the gap here. If I may employ an analogy, it’s a little bit like designing a chair with a business case and an artists rendition of the chair. In between this and a finished product there is a wide berth of decision making where there are no tools today. This is how it works at many modern software companies though.
This feels immensely inadequate. Like building physical products, there are many ways that the look, feel, and behavior of the software can affect the quality and the user experience (tons of research here). Good frontend engineers (underrated) will take into account many aspects of these ideas and make the software whole. Judging by the state of the industry however, this is the exception and not the rule.
This is compounded by the fact that building software is expensive and many teams are reluctant to make major modifications once code gets shipped. Part of this is motivated by concerns around opportunity cost, and parts of this is rightfully pulling the rug under users. This is exacerbated by the agile, A/B testing, metrics-driven culture that is pervasive in product engineering organizations. That, and the belief that user need transcends everything else.
This doesn’t feel quite right to me. There must be a way to improve quality without always going on expensive detours.
The hypothesis
There must be a way to build, test and validate ideas in software before turning them into extensive infrastructure projects that modern software development requires. This will be a prototyping tool that allows the user to quickly create throw away fodders that can meaningfully iterate upon the substance and material of the software product.
The way this tool works is by modeling and working with the data state. In an abstract sense, all software is is a data visualization problem. By providing tools to render and manipulate data – and we have a good set of vocabulary today through design patterns – we will be able to create a good facsimile of the idea that we want to test, and avoid a lot of the pitfalls that screen based prototyping tools have today which over emphasizes visual information and less the materiality of using the software itself.
Prior art
I’m reminded of a lot of programming languages and frameworks in the early aughts such as Visual Basic 6 and Flash. While these application frameworks are no longer relevant in the modern computing environment, there are a few qualities that they possess that can be useful to reference. They are as close as we got to What You See is What You Get.
Other adjacent solutions come to mind as well. The venerable Hyper Card. Visual programming languages like Max/MSP and VVVV all have the property of being incredibly dynamic. Many game design tools possess similar qualities as well.
The business case
The primary commercial challenge for this tool will be how it integrates into the current design-engineering workflow. Which is to say, poorly, because there is a lot of muscle memory built into the current design workflow which is highly dependent on Figma. Since Figma cannot be replaced, it will either need to live alongside it, or be subsumed by it.
That said, there is definitely potential for disruption but it will depend on the macro-environment changing. For one, if this tool comes into reality, and it can side step some of the needs that a pixel based tool provides (for example, it has a way to define design systems), it might reduce the need for a drawing tool. There might also be a change in the ecosystem where application development moves into other mediums or modalities like AI where drawing tools are a poor fit for, and that might move the needle the way Sketch did to Illustrator back in the day.