However, the article about DSL at AirBnB does not address my concern fully — how does one go from an existing component to a new component, design-wise, is my question? They seem to be mostly concerned with the consistency of the end result, especially in a large and diverse team. I wonder about the consistency of the interim results (which frequently end up being the end result).

For now, those interim steps are usually left to the software developer to decide on, meaning that until the full "migration" is considered complete, the component will be somewhere in between. And as projects are descoped and priorities change, it is a very real risk that components will be in that half-baked state forever.

I know that I have gone through the exercise a number of times, always leaving designers unhappy, because I implemented only parts of what they designed before I was pulled onto another project. And while I try to be cognizant of the design issues, I neither have the time, knowledge nor experience to do a good job of it.

If design instead provided incremental steps that are not necessarily half-baked, but just steps in the right direction, I think it would improve results developers put out, and at the time of "descoping", the component would still be consistent and usable.

It sounds like an entirely different axis to what the tools are providing today — we've gone from bitmap mockups, over vector mockups and state transitions, to interactive and explorable mockups and component libraries, but we are missing that "road" from "now" to "there" (a timeline of mockups with all the phases). I know designers can choose to do this "timeline" together with developers "manually", but it seems like a great thing for a tool to help with.

As a developer, I like being given a "feature" to work on, and I prefer not to break it up before hand — I start on something small that should bring some value and that will give me an idea of what step should come next. Basically, I know how I can develop an interim result that is of as high quality as the end result would have been: it just achieves different or fewer things.

I would expect a tool that has "current state" as the start, and maybe "end state" as the end (though in software engineering, we found out that the expected end state is never the end state), and it would allow a developer and designer to effectively work together to design the first step in a coherent manner that will take them both to the end state. "Coherent" is important here so it's not just a step towards the end state (which is what developers usually resort to, which are commonly artificial improvements which might not be improvements at all).