the simplicity shift - scott jenson

one of the better design books I've seen
straightforward, concise, broken up with case studies demoing ideas
conclusion/summary sections

about user centered design

4 types of company blindness
user blindness - assuming you know who the user is
feature blindness - too many features
innovation bl -
	not realizing the defaults you restrict yourself with
	thinking new ideas are too hard
implementation bl - not seeing things through execution

not about design tips and tricks or how to do field research
about design insight and management
focus on design tools and structure
for designers and managers

extra features add complexity nonlinearly
two buttons means >4 states and required knowledge about which to use when

comments on what is simplicity, its difficulty, and why is it valuable

view the user experience as something that happens throughout
the task, infrastructure, presentation of the product
not just presentation
be aware of the users background

case studies throughout the book

gprs phones study
analysis -
created scenarios for everyday, basic events and activities
	including eg losing signal in a tunnel
short slide pres. about scenario and resulting questions
	what happens if data lost during email download
	error message, inform?
people didn't agree/know what to do in these situations
tech standards often are not prioritized
	just long list of requirements
	many might not actually be needed
uncovered hidden assumptions

*personas
break users down into segments
describe key user types (just a few)
who they are and how they relate to the product
get an agreement and ranking of these
seemingly too many details about user help understand their perspective
helps prioritize goals

*scenarios
short description of what a persona wants to accomplish
	eg check for emails from the office, not download emails to inbox
	helps convey the feeling not just functionality
try to maintain context
can be structured as
	persona, having done x, wants to do y,z,...

*unfeatures
common things that go wrong with the product
	but are put off and dealt with poorly at the end of dev
addressing these early can save time and money
common examples
	setup process
	error recovery
	repetitive or discontinuous task flow
	sense of place

*priority trick
create a numbered list of all features
everyone ranks it in two ways (using personas)
	1 - frequency of use: 1rare, 2moderate, 3freq
	2 - importance: 1low, 2useful, 3critical
if too much high priority stuff, force people to bucket
add the two and sort
can be helpful to do this in terms of scenarios

*make easy easy, make hard hard
rule of thumb
complicated tasks are probably being performed by people willing
	to spend more effort
take advantage of this to give preference to simpler stuff
	bury lower priority, complicated stuff
"parsing shock"

prioritize features by identifying core set
	based on personas and scenarios
	then add extra things without disrupting this core

*see the water
try to be aware of and question the defaults
if you need to convince people, ask "why is ___ important"
sometimes legacy stuff is too strong to break from though

*embrace the impossible
sometimes designs are infeasible
but thinking they are is sometimes an opportunity to explore new methods
sometimes just misunderstanding
	eg it's not really a combined storage, just presented that way
	accidental conflation of different layers of the product
discover key concerns, alternative ways, assumptions about complexity

*fail fast
when starting or stuck, take a cheap guess and learn why its wrong
sketch, demo, test
can use various levels of polish: paper, wireframe, interactive stuff

*design manifesto
collection of basic goals and constraints of the project
2-3 pages, explain why it's being done and major hurdles
intro
	project name, start date, goal
tech issues
	standards, hardware req, most challenging tech issue,
	key tech interactions, key inflexible architecture,
	key flexible architecture,
	key assumptions eg single user fast memory intensive
	changes considered which won't be done
planning issues
	deadline, eng start date, number of people,
	rough plan, scheduled testing
design issues
	personas, scenarios, prioritized feature list,
	product sketch, features to be deferred, dropped
---
problems getting agreement are indicators of future issues,
	not defects of this process

*swat team
enforces design throughout execution
crossdepartment, meets as needed (more freq later)
helps to deal with inevitable things that show up during dev
mostly bug handling which affects design