Summary
Designer Brian O'Neill tells me what it takes to make a well designed piece of software.
Details
who he is and what he does; role as a designer vs developer; how to find out what is needed, getting feedback, including engineers in feedback process; what is great design, invisible interface, task flow, google as an example of good design, good task flow example, db tables should not dictate the view; who is responsible for good design; bridging the gap between designers and developers, learning design; steps in making a good design from the perspective of a designer and an engineer, laddering, sketch on whiteboards rather than using fancy software, user testing; why not to start from the data model; flexibility vs usability; engineers should be involved in user testing, self reflection; agile, incrementing rather than iterating, lack of user representative is common, design runway – designers stay ahead of engineers by a sprint, validation loops, don’t worry about what people like about an interface only what they do; definitions of success from different perspectives; working as an insider rather than as an external contractor; conflicts between engineers and designers, justifying decision making and intuition, sum of design errors reflect on overall product, building respect between engineers and designers; just because the big boys do it doesn’t mean you should; Brian’s music; author recommendations, Edward Tufte, Stephen Few.