The document provides guidance on designing successful products and systems. It recommends separating required functions from implementation details, abstracting requirements, solving the abstraction first before implementing, introducing constructive constraints, pursuing bigger design goals that are inclusive of all users, analyzing markets visually, and predicting inevitable futures. It also advises tracking your own annoyances to find problems to solve, performing root cause analysis, pursuing projects that matter more than money, and thinking bigger about opportunities to address massive challenges like climate change through creative problem solving.
5. SEPARATE REQUIRED FUNCTION
FROM IMPLEMENTATION (how)
mobile
cloud
redundant
list
dropdown
window app
remote
multiple
redundant
portable
search
host
http://www.axiomaticdesign.com/technology/axiomatic.asp
button
page
link
6. SEPARATE REQUIRED FUNCTION
(what) FROM IMPLEMENTATION
http://www.axiomaticdesign.com/technology/axiomatic.asp
available
scalable
performant
durable
affordable accessible
pleasant
7. SEPARATE REQUIRED FUNCTION
FROM IMPLEMENTATION
http://www.axiomaticdesign.com/technology/axiomatic.asp
Function
• attractive (to me)
• entertaining, fun (to me)
• stable/prestigious
Implementation
• tall, dark
• funny
• rich
14. Who is missing from
the future you’re
designing?
-Genevieve Bell
@feraldata
https://envisioningtheamericandream.com/2013/06/04/cheerios-and-american-diversity/
28. ROOT CAUSE ANALYSIS
When you hear passive voice,
ask who is doing it.
¯_(ツ)_/¯
https://en.wikipedia.org/wiki/Mistakes_were_made
https://en.wikipedia.org/wiki/5_Whys
34. Do you want to sell sugar water
for the rest of your life, or do you
want to come with me and
change the world?
– Steve Jobs
https://www.youtube.com/watch?v=S_JYy_0XUe8
36. STRAIGHT TALK ON CLIMATE CHANGE
https://thenearlynow.com/the-smokestacks-come-tumbling-down-c03ba1294522 - .t9h86fzi6
1.The reality is massive and terrifying.
2.The opportunity is massive, and will be
massively financially rewarding.
3.There is real reason for hope.
4.We cannot create a world we cannot
imagine.
5.The world needs creative problem
solvers. Go be a hero.
This approach is simple, but not easy.
This talk includes a lot of examples that are either not well known, or are well known and still not practiced. If you think “yes, I know that one” then ask yourself if you’re actually doing it as often and thoroughly as you could be. I first address #2 (design it well), and then #1 (design the right thing).
I borrowed this structure form Dan Gilbert in his 2006 SxSW talk: How to Do Precisely the Right Thing at All Possible Times.
This approach is simple, but not easy.
This talk includes a lot of examples that are either not well known, or are well known and still not practiced. If you think “yes, I know that one” then ask yourself if you’re actually doing it as often and thoroughly as you could be. I first address #2 (design it well), and then #1 (design the right thing).
I borrowed this structure form Dan Gilbert in his 2006 SxSW talk: How to Do Precisely the Right Thing at All Possible Times.
This approach is simple, but not easy.
This talk includes a lot of examples that are either not well known, or are well known and still not practiced. If you think “yes, I know that one” then ask yourself if you’re actually doing it as often and thoroughly as you could be. I first address #2 (design it well), and then #1 (design the right thing).
I borrowed this structure form Dan Gilbert in his 2006 SxSW talk: How to Do Precisely the Right Thing at All Possible Times.
If you can point to it (window, app, list, button) it’s implementation. Focus on getting a complete understanding of your function/capabilities first, then worry about how to build it. As soon as you start talking about any kind of implementation, you deny any other possible solutions and instead become entrenched on the path to that specific implementation. For example, saying “portable” means you need to have power, data transfer, interface, etc.
If you can point to it (window, app, list, button) it’s implementation. Focus on getting a complete understanding of your function/capabilities first, then worry about how to build it. As soon as you start talking about any kind of implementation, you deny any other possible solutions and instead become entrenched on the path to that specific implementation. For example, saying “portable” means you need to have power, data transfer, interface, etc.
If you can point to it (window, app, list, button) it’s implementation. Focus on getting a complete understanding of your function/capabilities first, then worry about how to build it. As soon as you start talking about any kind of implementation, you deny any other possible solutions and instead become entrenched on the path to that specific implementation. For example, saying “portable” means you need to have power, data transfer, interface, etc.
No one wants some hot water and some cold water. We want a comfortable temperature, and maybe a certain volume. Don’t let what comes out of the pipes dictate your UI.
Once you’ve defined the general abstracted case you can solve it purely abstractly, or you can look to other domains where similar problems have been solved and borrow their solutions. Then you can implement what you’ve figured out in any number of ways.
Make sure your team all agree on what your assumptions are and why. Display a poster of your assumptions. Ask people to add new unspoken ones and to disrupt/disprove any of them.
We love the idea of garage startups because they come up with creative solutions, inspired by their resource constraints.
Try adding and removing rules, tenets, or features, and see what you get.
Also, you mostly shouldn’t use dropdowns; they’re usually the wrong answer.
We love the idea of garage startups because they come up with creative solutions, inspired by their resource constraints.
Try adding and removing rules, tenets, or features, and see what you get.
Also, you mostly shouldn’t use dropdowns; they’re usually the wrong answer.
You can’t think outside your box, that’s why it’s your box. Get a bigger box by adding several boxes together. For best results combine several boxes that don’t all look the same, probably held by people who don’t look like you in some way (origin, education, life experience). Otherwise you limit your ideas, solutions, impact, and customer base.
You can’t think outside your box, that’s why it’s your box. Get a bigger box by adding several boxes together. For best results combine several boxes that don’t all look the same, probably held by people who don’t look like you in some way (origin, education, life experience). Otherwise you limit your ideas, solutions, impact, and customer base.
You can’t think outside your box, that’s why it’s your box. Get a bigger box by adding several boxes together. For best results combine several boxes that don’t all look the same, probably held by people who don’t look like you in some way (origin, education, life experience). Otherwise you limit your ideas, solutions, impact, and customer base.
Here’s some examples of your box.
Survey #1:
A: How many of you prefer manual transmission?
B: Guesses for what % of new cars sold in the US a manual vs automatic?
Answer: < 5%
Survey #2:
You’ve all heard of the institutional sexism at Uber, revealed recently by engineer Susan Fowler.
A: Male-presenting people only: how many of you have worked at a company where this was a problem?
B: Non-male-presenting people only: how many of you have worked at a company where this was a problem?
Contrast the response rates
Giving people data is OK, giving them an answer is better, facilitating the right action is best.
Complete solutions beat facilitated actions beat answers beat information beats data. A subscription (complete solution, no action required) is even better than the Dash button (an easy action).
Menus are sorted by how users expect to consume the food, not by name, price, calories, etc.
Represent data how users will think about it or use it. This usually isn’t how it’s stored in the database. Alphabetical is only a good sort order if you don’t have anything more important.
Your UI can fall anywhere on the spectrum from database to user.
Menus are sorted by how users expect to consume the food, not by name, price, calories, etc.
Represent data how users will think about it or use it. This usually isn’t how it’s stored in the database. Alphabetical is only a good sort order if you don’t have anything more important.
Your UI can fall anywhere on the spectrum from database to user.
Photo credit Noah Iliinsky, Belltown Seattle, 2010
The beautiful thing about hypertext is you can link anything to anything.
The terrible thing about hypertext is you can link anything to anything…
People design systems (badly) like building a house one room at a time with no blueprint. Spend the time architecting the user’s flow, not by screens but by actions and choices. Then you can talk about screens. Doing this will save you months of work later, and will result in a better product.
(Jesse James Garret coined the term AJAX in February of 2005 back before it was just how everything was all the time.)
The architecture map or flow diagram is a tool to to externally represent your thinking
Drawing the flow map or architecture diagram helps you understand the requirements
You have no business drawing the interface if you don’t understand the requirements
Bad / weird / messy maps indicate missing requirements
What happens to your system when things go wrong? What if the inputs are bad? What if it’s used improperly? Or maliciously? What’s the worst thing that could happen? You should ask yourself these questions every time.
See Microsoft’s twitter bot fail, and Gmail’s April fool’s joke fail (March & April 2016).
What happens to your system when things go wrong? What if the inputs are bad? What if it’s used improperly? Or maliciously? What’s the worst thing that could happen? You should ask yourself these questions every time.
See Microsoft’s twitter bot fail, and Gmail’s April fool’s joke fail (March & April 2016).
If your system depends on humans doing the right thing to be successful, it will necessarily, eventually fail. Designs systems that do the right thing in the absence of human action.
Direct deposit is a good example of a system that works properly in the case of human inaction.
Chernobyl is a bad example of a system that made itself worse in the case of human inaction. (And then the humans didn’t trust their instruments and made bad choices that made everything worse.)
This is also an arguments for strong defaults, by the way.
Note where in life you’re bothered by things, and where you’re resigned to things. These are areas rich with opportunity for improvement and innovation.
Root cause analysis is important. Treat the real disease, not the symptom. The visible problems are often caused by much deeper systemic forces.
Root cause analysis is important. Treat the real disease, not the symptom. The visible problems are often caused by much deeper systemic forces.
Figure out what axes domain the space you’re considering. Plot the current players along relevant axes. Look for where the gaps are. Fill them.
This is a Wardley map, by Simon Wardley. The underlying approach is based on the fact that lot of technological advancement is inevitable and predictable. Mapping industries and their technologies on this map can show you where the next advances could be made. Leverage that in a structured way to get ahead.
“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Gretzky
This is a Wardley map, by Simon Wardley. The underlying approach is based on the fact that lot of technological advancement is inevitable and predictable. Mapping industries and their technologies on this map can show you where the next advances could be made. Leverage that in a structured way to get ahead.
“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Gretzky
There’s a whole world of important problems to solve. Go find some. They’re probably not here. Do some real homework to understand the actual issue, not the surface symptom.
Paraphrasing Genevieve Bell “Who’s missing from the future you’re designing?”
Tim has been talking about this since 2009.
1. Good work shouldn’t have to be charity work, it should be self-supporting. People should work on issues they believe in.
2. AWS is a great example of a business that creates more business value for others than it captures.
3. Think beyond the next release, quarterly results, or vesting date.
[movie break]
A great example of working on things that matter. This is what Steve Jobs said to John Scully to hire Scully away from Pepsi to come be the CEO of Apple.
(Scully later fired Jobs, but that’s beside the point.)
Bret Victor is one of the smartest design thinkers working today. When asked what a technologist could to to help with the single largest problem humanity faces, climate change, he wrote this list of resources, suggesting a few of the many possible ways technologists can help.
The largest economic opportunity in human history is upon us. We need heroes to save the world, and likely get rich doing it.