A Project Guide to UX Design

"This book is abysmally written. At points, it takes full pages to say what could easily have been expressed in a single sentence. The visuals make me want to gouge my eyes out. However, the content makes up for the terrible writing. This book contains numerous essential details of how a UX Designer fits into a work environment--what the workflow is, the roles of coworkers, what tasks need to be performed, and when, and how. This book scopes itself ambitiously, attempting to serve as a guidebook to the disparate groups of UX students, practitioners, and managers. As far as I can tell, it addresses the needs of all three groups.<br/><br/>It includes numerous call-outs of references for additional reading, categorized as "surfing," "snorkeling," or "deep diving" based on how long they'll take to read (and how in-depth they are). Judging by the ones I've read, these seem generally to be a good collection of resources.<br/><br/>The two authors bring different perspectives to bear upon the book. Chandler's chapters provide a great deal of information about the logistics of dealing with the business side of the job, what paperwork to complete and what meetings to hold. Unger's chapters focus more on how to interact with sample users and how to map out and test the site.<br/><br/>From inside the book:<br/><spoiler><br/>- A UX Designer generally has to fulfill the three rolls of Information Architect, Interaction Designer, and User Researcher and will also either interact with or act as a Branch Steward, Business Analyst, Content Strategist, Copywriter, Visual Designer, and Front-End Developer.<br/>- Project teams use various approaches to development, including waterfall, agile, and lean approaches. Agile works well in small teams with frequent deadlines. The lean UX approach is a type of agile that looks at each iteration not as a product, but rather as a hypothesis of a design that may work for users and that should be iteratively refined.<br/>- In gathering requirements, it's essential to understand the motives for having those requirements before turning them into features.<br/>- There are at least six user-research techniques: user interviews (to learn more about the target users), contextual inquiry (to learn more about the target users in their natural environment), surveys (to gather qualitative data about preference), focus groups (to understand user attitudes), card sorting (to create categories), and usability testing (to see how users use the product). <br/>- Make sure that content is created early on and then build the project around it rather than trying to populate content after the project is built.<br/>- Drawing multiple sketches is a good way to wireframe because it gets your past the first few obvious ideas.<br/>- A prototype doesn't need to represent the entire system; it can represent just the parts you're interested in testing. Unless you're testing something like the discoverability of page elements, it doesn't need to look remotely realistic.<br/>- It's a good idea to get involved in QA (and later in analytics) to see a design through after the initial design phase.<br/>- In screening potential users before a usability test a good way to out of conversation with users who don't fit basic requirements to be good test subjects is to tell them that they fit into a group that you've already filled but that you would be interested in contacting them for a later test.<br/>- It's important to send out meeting notes soon after the meeting to create a paper trail of decisions and to avoid letting debates revive as people's recollections change.<br/></spoiler>"