Play, make, or not

I’m building an app for building and testing design prototypes. I call it Playmake. It will probably not be finished.

Here’s what I have so far: the main view is a canvas for drawing out UI elements. This is similar to other vector drawing programs, and in this version you can draw rectangles, color them, and add text.

Very often, the design process is in sussing out the how data is presented in the UI. To these ends, the app has a data grid view that can be used to store sample data for the prototype.

Once both of these are constructed, the canvas can be linked to the data grid. The idea here is that interactions can modify the data grid and thus represent real data in the prototype (the implementation is incomplete).

You can play with the current build here. It is built with Pixi.js as the canvas and written in Typescript and React.

The starting point

Before starting to work on Playmake, I have been mulling over the software design process and the deficiencies in our day-to-day. There is a tendency for software to look beautiful but not work well, and this signals to me a gap right now (I wrote about the gap here in more detail).

It seems obvious:

1. Design tools today are really focused on how things look. They come from a lineage of raster and vector graphics and many built-in concepts excel for working in high visual fidelity ¹.
2. The prevalent way of building software in modern teams is to let the UX design team worry about the look and feel while the PM and engineering team worry about how things are built.
3. UX tools and processes are poor at modeling and representing complex interactions and user states ².

For software to work better, we will need tools that help designers think through how software works in much higher fidelity. This would require thinking through not just the interactions at the control level, flows, how data is represented, manipulated, as well as how state effects and is affected by the user.

Playmake stems from that thought. That software design should be represented as a data visualization problem. That modeling the data is crucial to the design process. And one way to elevate is to take the familiar tools we have a layer on a methodology to connect them together.

I stopped working on (this version of) Playmake

After playing with this build extensively, this does not feel like the right solution space. For one, it felt clunky. There were just too many knobs to turn and buttons to click to get anything set up. It takes a lot of work to wire anything together right now, and while that can be simplified somewhat, the complex scenarios that I want to solve for feels insurmountable.

I imagined it as simply being a canvas that can be made interactive. In reality, to make something like this “dead simple” would require a lot of scaffolding. Scaffolds are leaky³ molds, and like molds, constrains the idea into rigid shapes; after all, to provide a happy path requires taking away options and configurations. As this effort progresses, it started to increasingly look like building a language, framework, and interface builder all in one. The more I made it tangible, the less it felt simple.

To take this implementation to fruition will mean covering a lot of ground. A blind spot– something I missed by virtue of being an expert user in current design software–is that they are remarkably complex applications. These are not easy software to learn, and proficiency is achieved by internalizing tons of minute gestures and keyboard shortcuts, which leads it to feel frictionless. Even when building this prototype, I added a lot of little bells and whistles so that using it felt more “intuitive”. Even then, it wasn’t enough. This felt a lot for a solo effort, and what I thought were small grounds end up being large swaths of plains.

I spoke to colleagues of mine who are UX designers about Playmake. While people are intrigued, there does not seem to be a natural spot for this tool to fill in. In this current iteration of product engineering team the roles of design and engineering are well defined and this tool straddles the gaps in between a bit too much. Designers will still be expected to produce high fidelity UI work and engineers will still have to implement designs that are constrained by UI frameworks and design systems. There is less space than I imagine for such free spirited exploration I fear. Playmake replaces neither⁴.

What comes next

All of this adds up to a very steep uphill. For something that I’m working on by myself, the amount of novel to foundational simply feels too lopsided. This may be a worthy venture for someone well funded who can push it into fruition. The dent I can make here is going to be miniscule for the amount of resources I can pour in, even if discounting idea and effort risk.

This is not to say the problem is not important, or that I’m moving onto other things. Put differently, if I were to make a contribution to the field here, it is going to come from an effort that I can reasonably achieve myself. For that to work, the potential upside of the idea and exploration will need to vastly exceed the labor required.

This idea does not tilt that way and that is why I’m not shipping Playmake. Overall, I’m glad to have tried. It’s a bit of a pity, but hey, I scratched an itch.