3 ms·

This is the announcement of a new paradigm that Don has been thinking about recently, it is not meant to be practical advice for implementation. It imagines a w

This is the announcement of a new paradigm that Don has been thinking about recently, it is not meant to be practical advice for implementation. It imagines a world where a designer is not needed to create a product; a designer can help refine, share, or scale it. In tech it would be something like those non-programming work flows for the marketing departments, which are typically looked down upon by the technically knowledgable, but imagine if they instead took that as the inputs to design a better system. (Disclosure: Don is a relative.)

wtracy 8y ago
Your post addresses my biggest problem with the article: It reads more like a wishlist than a guide. I would like to these issues addressed going forward: (And please don't take this as a list of reasons why this won't work; these are all things that I think can and eventually will be addressed.) 1. How do the stakeholders learn what is or isn't technically feasible? (I've seen stakeholders propose cumbersome solutions because they had no idea that the technology existed to make something better.) 2. How do the stakeholders learn about the non-obvious trade-offs between different design options? (As a trivial example: Lots of first-time product designers learn the hard way not to use white for the plastic exteriors of electronics. Why? It's extremely difficult to get white plastic to have a consistent color, and the two halves of the shell won't match. Even Apple, with their massive budget, struggles with this.) 3. How do stakeholders learn about prior art in the field? There's rarely a good reason to reinvent the wheel, and there's even more rarely a good reason to repeat other people's mistakes. 4. How do the stakeholders communicate their design to the engineers accurately and unambiguously? 5. How do you accomplish all of the above without constraining the stakeholders to design by multiple choice (which is still inherently limited by an outside expert's idea of what is and isn't going to be useful to the stakeholders) or forcing them to become domain experts themselves? If I have a suggestion off the cuff to address (some of) these issues, it would be to make a tiered set of design tools available. Level 1 would be straightforward multiple-choice, level 2 would be a mix of fill-in-the-blank and click-and-drag, up to level N using the same tools as the professionals. Community stakeholders could then decide for themselves what is the appropriate trade-off between flexibility and time investment.
ThomPete 8y ago
Its not a new paradigm,its a framework and its more or less just design thinking reformulated regardles of his intentions. Move fast and break things was a new paradigm. Design thinking sounds great on paper but is only as good as the cogs in the wheel and therin lies the problem. It doesent offer any transcendence between insights and application. It doesent pass the no-test. To the extent that a designer isnt needed neither is the non designer who should be doing to design instead.

wtracy 8y ago

Your post addresses my biggest problem with the article: It reads more like a wishlist than a guide. I would like to these issues addressed going forward: (And please don't take this as a list of reasons why this won't work; these are all things that I think can and eventually will be addressed.) 1. How do the stakeholders learn what is or isn't technically feasible? (I've seen stakeholders propose cumbersome solutions because they had no idea that the technology existed to make something better.) 2. How do the stakeholders learn about the non-obvious trade-offs between different design options? (As a trivial example: Lots of first-time product designers learn the hard way not to use white for the plastic exteriors of electronics. Why? It's extremely difficult to get white plastic to have a consistent color, and the two halves of the shell won't match. Even Apple, with their massive budget, struggles with this.) 3. How do stakeholders learn about prior art in the field? There's rarely a good reason to reinvent the wheel, and there's even more rarely a good reason to repeat other people's mistakes. 4. How do the stakeholders communicate their design to the engineers accurately and unambiguously? 5. How do you accomplish all of the above without constraining the stakeholders to design by multiple choice (which is still inherently limited by an outside expert's idea of what is and isn't going to be useful to the stakeholders) or forcing them to become domain experts themselves? If I have a suggestion off the cuff to address (some of) these issues, it would be to make a tiered set of design tools available. Level 1 would be straightforward multiple-choice, level 2 would be a mix of fill-in-the-blank and click-and-drag, up to level N using the same tools as the professionals. Community stakeholders could then decide for themselves what is the appropriate trade-off between flexibility and time investment.

ThomPete 8y ago

Its not a new paradigm,its a framework and its more or less just design thinking reformulated regardles of his intentions. Move fast and break things was a new paradigm. Design thinking sounds great on paper but is only as good as the cogs in the wheel and therin lies the problem. It doesent offer any transcendence between insights and application. It doesent pass the no-test. To the extent that a designer isnt needed neither is the non designer who should be doing to design instead.