My notes from Rob Treat's talk at Velocity Conf EU 2014:
* "A designer is an agent that specifies the structural properties of a design object"
* for design, we mean utility, not aesthetics
*perceived affordance – quality that suggests how to use an object
* affordances can provide feedback mechanisms
* you should consider this when designing things like alert handling protocols. Do you ACK the alert before fixing, or after. What is visible to people other than the people on call etc?
* design things with a natural mapping for the context in which they are used
# Example using Postresql
** `psql -d` where -d is the --dbname
** `pg_restore -d` where -d is the --dbname
** `pg_dump -d` where -d is --inserts. WAT?!
* This was removed in v8.4 of PG, and added to be consistent in PG 9.3. Mailing lists have lots of threads complaining about the friction
# Success must be distinguishable from failure
** status codes
** output cf TAOUP Rule of Silence
* Forcing functions
** Microwaves don't work with the door open. You can try to route around that eg drill a hole in the door, but then you'll probably become a candidate for the Darwin Awards
** Some cars need to be in Park before you can remove the keys from the ignition
# Make it hard to do the wrong thing
* For deployment pipelines verify that:
** the version of code is in prior environments prior to promoting it
** there are no unhandled alerts in the context environment
Plug for Don Norman's book