Weinschenk, Susan. 100 Things Every Designer Needs to Know About People. Berkeley, CA: New Riders, 2011. Print.

Weinschenk is psychologist and an interface designer. She writes and consults about applied cognitive psychology in the field technology. This little book contains facts about the way humans see, read, remember, think, focus, feel, decide, make mistakes, relate socially, and are motivated. It is exactly the type of knowledge Hoekman advices learning to make good situational scenarios to guide design. This information helps both interface design, and content creation. About 40 % of the facts seemed relevant to my project, both for the web design and for the creation of compelling interviews. Here are some nuggets:

Web Design

• People scan based on past experience and expectations. Incorporate conventions.
• People see cuesthat tell them what to do with an object. The movie player buttons.
• People believe that things closer together belong together. Use chunking, and allow enough space between unrelated items.
• Meanings of colors vary by culture. Does this extrapolate downward to sub-culture, like Evangelical Christian Americans?
• Reading and Comprehending are two different things. Goal is useful information that is understood and acted upon, not text.
• Reading a computer screen is harder than reading paper. Pay attention to fonts/colors/size/line length/etc.
• People process information in bite-sized chunks. Description, instructions, information needs to tight.
• People remember only four items at once. Implications for tags, searches, and organization schemes. Limit choices to a manageable load.
• People create mental models. Design must conform to mental model for ease of use, or it must easily teach a new model.
• People interact with conceptual models. Keep in mind the user, who will be doing and learning from the model/application you create. Limit activity that is unhelpful/difficult/confusing to them, reward activity that helps them achieve goals.
• Well practiced skills don't require conscious action. If immersion is the goal, the architecture of the application needs to be invisible. Conventions.
• People can't actually multi-task.  Immersion is a viable goal.
•  People want more choices and information than they can process. True UCD is about goals and applications that meet those goals, not stated desires.

Interviews

• People are hard-wired for imitation and empathy. The sympathetic of exemplary lives can motivate people to emulate godly attitudes and habits.
• Doing things together bonds people together. Stories of a shared faith-life.
• People expect online interactions to follow social rules. Should resemble church setting sharing, not media iterview.
• Speakers brains and listeners' brains sync up during communication. (mirror neurons) The conversation between myself and listeners is a vital ingredient.
• People can enter a flow state. Edit to hold attention.
• Culture affects how people think. Care about straddling two cultures, individual church affiliation and common Christian and American.
• People process best in story form.
• Anecdotes persuade more than data.
• People use look and feel as their first indicator of trust. (careful set design strategy)
• Pastoral scenes make people happy. Outside interviews?
• The more difficult something is to achieve, the more people like it. Discuss weight matters.
• People make most decisions unconsciously. The act of sharing story impacts decisions.

Hoekman, Robert. Designing the Obvious: A Common Sense Approach to Web and Mobile Application Design. Berkeley, CA: New Riders, 2007. Print.

Hoekman writes a book that is very similar to the other advocates for "user-centered" design strategies, yet with a twist. He offers all the standard fare; a user-centered design schema, simplicity as a virtue, the need to design accommodating/polite/intuitive interfaces, resistance to feature creep, refinement strategies, etc. He also adds a timely admonition and chapter to "Think Mobile," I find particularly helpful. Where Hoekman offers something new is in his rejection of Cooper's use of personas for modeling the end user.

Hoekman does agree on modeling, but prefers designing for particular behavior/task over a fictional personas.  He believes personas are confusing and an unnecessary distraction for designers, and because Cooper uses personas in conjunction with scenarios Hoekman says the backstory is superfluous and the scenario is the key. Design for the situation, because it doesn't matter who the user is the rest of the time, when using your application they are all the same. Research should focus on how people think and the ways they go about tasks involved with your application. The data is still collected through ethnographic research techniques, and still creates fact based models, but there is no character accompanying the model. This makes some sense if, as Hoekman asserts, design teams get bogged down in the fictional backstories accompanying personas. It could be situational design strategies, when coupled to other evolved conventions like simplicity, clean task flows, and machine courtesy are sufficient to the task. It would simplify the design process. Steve Jobs died a few day before this post, and he famously did not do user research but his own team's common sense to design state of the art, elegant interfaces.



Key Takeaways


Quickly transform Beginners to Intermediary users. I have read this before. Users to technology don't stay beginners very long. If it is well designed they learn what is necessary and useful to their goals, if not they give up. Also, users rarely become experts, so avoid overcomplicated design or a plethora of features. The goal is a quick and painless ramp up from first-time user to competent (if not expert) frequent user.


Learn and use Psychology.  Not "I'm okay...You're okay," but what does cognitive psychological research teach us about memory, the way people process data, colors, etc.


Think Mobile. The idea here is to think of your application existing beyond the bounds of a desktop computer screen. Will it work on a smart phone, on a moving and noisy bus? He suggest keeping a tablet and phone beside your work station as you design to help consider the other vehicles for your app.

Garrett, Jesse James. The Elements of User Experience: User Centered Design for the Web and Beyond, 2nd Edition. Berkeley, CA: New Riders, 2011. Print.

Garrett does main strength is in describing the design process. He lays out five "planes," or levels of activity making up the web design process. He created this diagram, that is widely referenced in other literature about user centered design:

Image from: http://www.jjg.net/elements/

I found this to be most useful for visualizing the process of website creation as a totality, but unable to answer many questions about implementation priorities. First,  while the requisite "user-centered" phrase is often mentioned in his book, and is conceptually foundational to his schema, he doesn't elaborate on how one gathers information about the user, or integrates that knowledge into the design. The other issue, a key one for those interested in developing content, is his emphasis on the technical demands of the interface over the rhetorical demands of content creation and maintenance. Kristina Halvorson points this out in Content Strategy for the Web when she writes, "...content is not a feature. It's a complex, ever-evolving, intricate body of information that requires ongoing care and feeding. It's not something you can check off on a list and be done with." Garrett concept of content, appearing as a design consideration only in the planning phase, reveals a limited view of the user. The designers in this system only need to think of the user as he or she relates to the interface and information architecture, not a person pursuing other goals, that just happen to be happening over a digital interface.

Our tradition, while considerate of the technological platform and its role in shaping and delivering messages, emphasizes the communicative act over the technology. Garrett's book is written too much from the perspective of the developer and the technological demands, and not enough from the perspective of the user, or those tasked with understanding and serving that users desires. Though his design process has merits, it needs modification to be truly "user-centered."