In the previous post, I wrote:

Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, but once you are in the implementation zone, that space changes to more of an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table.

If you are in a semi-waterfall logic, the quality of your initial ideas becomes more important. And let’s be honest, when you’re designing software, most of us are in a waterfall process at some level.

Surely there is some leeway in influencing the idea while it’s in development, but the space you move in severely limited by whatever analysis and design work was done before you, typically already limiting the possibility space. And it’s not just limited by your design; the limit might also come from an analysis, prior design, or legacy part of your software.

Not every type of design work follows the above order of going from idea to implementation. Some designs stay in the possibility space, and are specifically meant to be an output to help further business discussions; or are meant to gauge product/market fit.

I’ve had to learn to navigate the space of having hundreds of active designs, where some of them are closer to an implementation and some are merely an idea.

I’ve identified three types of designs in product and categorize them as A, B and C designs:

• A-type designs: The scope is more or less defined, there is an analysis, this design is going to development soon. Detailed questions about edge cases should have answers, and the design better be in a ready-to-implement state.
• B-type designs: The scope is probably to be developed in 4-8 months but might also be cut. You are exploring solutions with much more possibility for divergence than in A-type designs. You are working towards a solution, but it’s OK if not everything has been thought through.
• C-type designs: this design is not meant to be implemented at all, and does not have to take into account the reality of development. This design is meant to evolve a stakeholder discussion, to drive a client conversation, to simply document an idea, or to provide a vision and blueprint for the future that can inform B-type designs.

So, that’s it for today. My next post I would like to focus on some oddities that are going on in product regarding design systems.

If you like my writing about product, let me know, because I don’t know if these ramblings resonate with other designers/devs/product people!