Name: Change by design
ISBN: 9780061766084

Change by design

The myth of innovation is that brilliant ideas leap fully formed from the minds of geniuses. In reality, most innovations are borne from rigor and discipline. Breakthrough ideas-whether for a new bicycle, an advertising campaign, a treatment plan for diabetes, or a program aimed at tackling the national obesity epidemic-emerge not by chance, but by studying and embracing the immediate challenges we encounter every day in our offices and homes, laboratories and hospitals, classrooms and conference rooms, and in all the spaces in between. We don't simply realize solutions; we design them. In this book Tim Brown, CEO of the celebrated innovation and design firm IDEO, introduces us to design thinking. Design is not just about creating elegant objects or beautifying the world around us. The best designers match necessity to utility, constraint to possibility, and need to demand. These design thinkers rely on rigorous observations of how we use spaces and the objects and services that occupy them; they discover patterns where others see complexity and confusion; they synthesize new ideas from seemingly disparate fragments; and they convert problems into opportunities. Design thinking is a method in which genius, in the end, is not required. Design thinking is valuable not just in so-called creative industries or for people tasked with designing products.

What Hacker News says

JugurthaNov 2020

>that has validated idea

I assume you have users, then?

>My question is, how often you look at competitors and see what features they are offering

What are your users doing or not doing? Do you talk with your users or provide a way for them to voice frustrations or delight? What are they complaining about frequently? We tend to focus on things that have a higher impact and frequency, just from a development optimization point of view: the backlog is large and we must prioritize somehow.

For example, at some point our users were having trouble training models using the notebooks due to "Out Of Memory". The kernels kept crashing. That is high impact, because there's a loss of work. It's happened to enough people on a regular basis because there was a "tragedy of the commons". After the nth person complains, it was clear what we had to do. Stop everything else, and fix that. We introduced long-running notebooks[0]. This also fixed an issue they were having when a notebook would be running, and users suffered an internet disconnection. The computation would take place in the kernel, but the front-end would not receive the results: this is common in notebooks, and one of the reasons people "save" their models and files. Now even when they disconnect or close their tabs, they can see the output as the notebook is being executed.

Another example: users would ask us for help or ask each other for help to troubleshoot their notebook. They would share screenshots of tracebacks or error messages. We added near real-time editing so people could work on collaborative notebooks, correct each other's mistakes, etc.

We needed to have the finger on the pulse and talk with users (on Slack in our case).

There's a book by Tim Brown titled "Change By Design: How Design Thinking Transforms Organizations and Inspires Innovation"[2]. We built a lot of custom machine learning products for enterprise, and one way to think about this is in terms of "Feasibility, Desirability, Viability". It's pretty useful.

One way to think about it also is in terms of "Jobs to Be Done"[3], with a nice piece by the late Clayton Christensen. What is it your users want to do. This was necessary again in building product because what the customer/client says they need is an implementation of a solution to a problem, not the problem itself. "I want a button to do X" is a solution you must not accept at face value, dig in deeper to find the problem and the job this is trying to do.

One point I'm trying to make is that, granted, some features are required, but it's not really productive to have your product development lead by "competitors". There may be things like best practices, but you must know why you are adding one feature or the other, and it better be something other than "competitor X has it" or a random internet person said it was cool.

You can create issues for them to capture the idea, then discuss it, augment it, and at some point probably kill it. Is that feature really core to your product or is it just a cute butterfly you're chasing.

Also, delegating is not just for people. You also delegate to products or tools. For example, our exercise is a "systems engineering" example. We're not going to reinvent a notebook because JupyterLab does that very well, and in our seven years shipping actual machine learning products for paying customers, we never thought "geez, if only Jupyter had better stylesheets this project would be moving so fast". So we'll limit the scope.

This is similar to Zawinski's "law" of feature creep: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can"

Not doing that would send anyone into recursion until they reinvent transistors, semiconductors, atoms, and electroncs. You have to know when/where to stop/start and contain the scope.

>For example, Secure Sign In, Login with [FB,Google,Apple], integrations with X etc.

How many people have asked for that? Why are they asking for it and what do they want to do with it? Is it what's holding the product back? How many are paying for it?

"But... we need that to land enterprise clients". Sure, how many enterprise prospects have you talked with? Have you met them? Did you get only the buyer or those who use it too? Can they try your software and give you feedback without their boss being in the room (assuming this is something old school with a buyer/user dichotomy). Did they say they'd "buy" the software if this feature was there? Did they sign a letter of intent? Is this a peculiarity? You're adding a barbecue to a car. "It'd be great if you could have a barbecue while driving on long trips". This is a caricature, real life is more subtle and these features creep on you until you have a product that's made of pieces of a thousand other products. A monstrosity.

Granted, there are sine qua non features, but you must know these and why they are deal breakers before adding them on.

- [0]: https://iko.ai/docs/notebook/#long-running-notebooks

- [1]: https://iko.ai/docs/notebook/#collaboration

- [2]: https://www.ideo.com/post/change-by-design

- [3]: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done

thread

JugurthaApr 2018

For those interested, IDEO's CEO, Tim Brown, has written an interesting book entitled "Change by Design".

thread

ryanSrichOct 2016

Here's a list of all design books that I give to new hires:

Branded Interactions: Creating the Digital Experience - (https://www.amazon.com/Branded-Interactions-Creating-Digital...)

The Visual Display of Quantitative Information - https://www.amazon.com/Visual-Display-Quantitative-Informati...

Universal Principles of Design - https://www.amazon.com/Universal-Principles-Design-Revised-U...

The Interface: IBM and the Transformation of Corporate Design, 1945-1976 - https://www.amazon.com/Interface-Transformation-Corporate-19...

Multiple Signatures: On Designers, Authors, Readers and Users - https://www.amazon.com/Multiple-Signatures-Designers-Authors...

Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation - https://www.amazon.com/Change-Design-Transforms-Organization...

Thoughts on Design - https://www.amazon.com/Thoughts-Design-Paul-Rand/dp/08118754...

Notes on the Synthesis of Form - https://www.amazon.com/Notes-Synthesis-Form-Harvard-Paperbac...

..and a list of ones I'm considering adding:

Unflattening - https://www.amazon.com/gp/product/0674744438/ref=oh_aui_deta...

Creative Confidence: Unleashing the Creative Potential Within Us All - https://www.amazon.com/gp/product/038534936X/ref=oh_aui_deta...

The Design Method - https://www.amazon.com/gp/product/0321928849/ref=oh_aui_deta...

Product Design for the Web: Principles of Designing and Releasing Web Products- https://www.amazon.com/gp/product/0321929039/ref=oh_aui_deta...

thread

avni000Oct 2013

Change by Design by Tim Brown

thread

danhodginsDec 2011

Brilliant example of the design thinking process in action.

This man has certainly practiced the 'design thinking' process outlined by Tim Brown in "Change By Design" - a book about the process of innovation. The Design Thinking process involves lots of ethnographic research, and developing empathy for the user - the same tenets as user centered (UCD) or human centered design (HCD).

In this case, the inventor developed empathy by going so far as wearing a fake uterus that emitted goats blood!

I find this story and others like it to be very inspiring. However, knowing that the world can be changed for the better or worse by people who believe strongly enough about something is both reassuring and frightening at the same time.

thread

JugurthaFeb 2021

Writing people can understand and act on. Writing that ties several threads and abstraction levels when different audiences will be consuming it. For example, when writing an email and the recipients are executives, managers, sales people, engineers, advisors, and advisors, I write what I call "fractal communication": an email that makes sense at different abstraction and "zoom" levels. A pre-requisite to do this is to know your audience and what matters to them, and how they view things.

I'll write an email that describes the high level objectives and the strategy I think will lead to success, then describe why I think it is true, then describe the hurdles, and then go deeper for what needs to happen right to the issue number on our issue tracker, and a pesky line of code or pull request on a third-party library.

Everyone has a receptor to bind to or a port to plug into.

It is also useful to write the "bottom line up front", or "BLUF"[0]. Conclusion, then the underlying research and data that lead you to reach that conclusion. If there are actions people need to take, write those at the top properly tagging the people who need to do them.

Another useful "skill" is "problem solving". We're a tiny boutique consultancy specializing in machine learning, and we have good outcomes working with our clients because we spend the necessary time to extract the problem out of our clients and clearly define it, and then solve that problem. We're not "AI enthusiasts/influencers" and we don't shy away from telling clients they don't need machine learning for the problem we identified. We've been approached by many who want the stereotypical "AI blockchain IoT" and we don't like solutionism.

Books:

- "General Methods for Solving Physics Problems". It is a book that recognized the problem many students have: they know the formulas and laws but they don't where to apply them, when, and how to know what a problem is, or when a problem is solved. Its definitions are delightful.

- "The Complete Problem Solver" by John R. Hayes. The book This is not a quizz collection, but an abstract way to think about problems, and then practical techniques to solve them.

- I recently discovered a book titled "Cracked It!: How to Solve Big Problems and Sell Solutions Like Top Strategy Consultants". I only skimmed the table of contents for now and seen the authors talk about it, and it looks like what we do with clients.

- "Change by Design" by Tim Brown. There are many useful concepts in there, but that also describes our approach, especially when they talk about "desirability, feasibility, viability".

Finding the right questions to ask, identifying the problem, then solving it will save you.

The skill of reading and synthesis is useful when diving deep in a domain. We work in diverse sectors and industries, and we must quickly be able to communicate with domain experts to define problems and find solutions. There's a large amount of reading and understanding to do. That is valuable for the project itself, but also for subsequent projects.

Another extremely useful skill is interviewing. We talk a lot with domain experts, and we must know how to extract problems from what they describe, frame the conversation, drive them to explain more, etc.

Generally speaking, there are many skills like design, "business", sales, marketing, that are very useulf.

- [0]: https://en.wikipedia.org/wiki/BLUF_(communication)

thread