Guaranteed successful design!
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.
1. GUARANTEED SUCCESSFUL
DESIGN
1.Design the right thing.
2.Design it well.
http://www.randomhouse.com/kvpa/gilbert/index.html
http://www.lukew.com/ff/entry.asp?294
@noahi
2. GUARANTEED SUCCESSFUL
DESIGN
1.Design the right thing.
2.Design it well.
http://www.randomhouse.com/kvpa/gilbert/index.html
http://www.lukew.com/ff/entry.asp?294
@noahi
3. SEPARATE REQUIRED FUNCTION
FROM IMPLEMENTATION
mobile
cloud
redundant
list
dropdown
window
app
available
scalable
remote
performant
durable
multiple
redundant
portable
affordable
accessible
search
host
http://www.axiomaticdesign.com/technology/axiomatic.asp
13. DESIGN SYSTEMS FOR HUMAN INACTION
http://www.nrc.gov/reading-rm/basic-ref/glossary/moderator-temperature-coefficient-of-reactivity.html
14. FINDING THE RIGHT PROBLEM TO SOLVE
1.Keep a bug list
2.Keep a resignation list
15. ROOT CAUSE ANALYSIS:
INVESTIGATE WITH FIVE WHYS
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
20. 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
Awesome, you found the speaker notes! Please enjoy the talk!
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 practicing 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 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 practicing 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.
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.
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.
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.
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.)
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 absence of human action.
Chernobyl is a bad example of a system that made itself worse in the absence of human action. (And then the humans didn’t trust their instruments and made bad choices that made everything worse.)
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.
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
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.
Good work shouldn’t have to be charity work, it should be self-supporting. People should work on issues they believe in.
AWS is a great example of a business that creates more business value for others than it captures.
Think beyond the next release, quarterly results, or vesting date.
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.