There is a missing tool in my design workflow. Because it doesn't exist, I have to borrow pieces of it from several other tools. I use a vector drawing tool like Illustrator to make wireframes, I use a raster drawing tool like Photoshop to make assets, and I use Quartz Composer for interaction design and animation.
The result is a frankenstein-like workflow that requires constant context switching. Worse than being inconvenient, the inefficiencies of my tools result in poorer solutions to design problems. The longer it takes me to explore an idea the more attached to each idea I become and the fewer ideas I explore. And because my tools are unnecessarily technical, its easy to become distracted solving implementation problems instead of design problems.
"We shape our tools and thereafter our tools shape us." —Marshall McLuhan
I'm not sure what the ideal software design tool looks like, but I'm convinced that it's coming and it will make workflows like mine seem primitive. Bret Victor has explored some interesting ideas in this space and has written about the subject as well. In lieu of an actual proposal, I compiled a list of criteria that I think an ideal design tool would satisfy.
You design by directly manipulating the artwork, not through a layer of abstraction (like code or patches). Feedback while designing is continuous and instantaneous.
The tool supports the same inputs and has the same properties as the medium being designed for. Any difference in how the tool behaves and how the medium behaves will limit the types of ideas the designer can have. The tool should encourage the designer to solve the right problems in the right order.¹
Separate the data
Views are separate from the data. Layouts are not dependent on any one dataset. Using real or representative content should be trivial so as to avoid designing for the ideal.
Design is implementation
Design is not separate from implementation; there is no need for an engineer to make the design "real" by implementing it in code. And because the designer is responsible for implementation, she is exposed to the constraints of the medium. These constraints will inform the design instead of creating feedback loops where engineers tell designers what is and isn't possible.
The tool has the right level of abstraction. Too much abstraction will limit the types of ideas that the designer can have; not enough abstraction will slow the designer down and force her to solve unnecessary technical problems. The designer can move up and down levels of abstraction while she works. If a particular abstraction is inappropriate or needs to be modified, she can do so on the fly. If the appropriate abstraction doesn't exist, the designer can create it. And because the tool is adaptable it will evolve to support inputs and displays that do not yet exist.