One of the fun things about serving software again is that I feel like I’m working in a startup. I mean this less in terms of the economic conditions of the business and more in terms of process:
- Prototype fidelity (low, fast)
- Layers of approval (none, do what you can do)
- Process (push fast, QA/test, adapt)
- Consensus & critique (this looks good & I have notes)
Which is especially interesting as a designer. It’s always been the case that the actual design I’m doing matters less than whether & how it ships, but with such a fast turnaround cycle and so few layers of approval, you really can do quite a lot more.
If you’ve been reading these letters for over 6 years or so, you know that I once wrote a lot about how designers will code, and that learning code is how you create higher-quality design. Now the roles have flipped, and I think a lot more about how developers will learn the basic principles of design. Ultimately we’re all making design decisions, and in independent software businesses, many decisions will be made outside of a designer’s influence.
There are many powerful economic reasons for developers to learn at least a little about design. First, the two roles will get along better, and operate with less contention in the midst of building & critique. But also, the product will be more enjoyable to use – which will improve conversion & reduce churn. And prioritization gets a lot easier when you learn about the tradeoffs inherent in specific design decisions.
And so the question then becomes: what would you teach a developer about design? There are plenty of “design for developers” resources out there, but there are also a lot of design topics out there. Here, we practice a specific form of design that blends research with experimentation, which is more focused on overall process than the actual nuts & bolts of little-d design.
I think most developers don’t need that, though. Most people aren’t going to pause their programming work to interview customers. Measurement is everybody’s job in independent software. Instead, other team members probably need the fundamentals: the stuff you learn right away that ground your taste and establish product quality.
I might be wrong, of course, but if true then that’s quite a fun challenge. How do you start over when it comes to teaching people? Do you hand them somebody else’s book and be done with it? Or do you follow your own path?