This book is short, well written, and gives the reader a LOT to think about. I’ve been reading it in small bits because I end up taking so many notes.

Chapter 3 – The Process

The systematic inquiry for research:

  1. Define problem
  2. Select approach
  3. Plan and prepare research
  4. Collect the data
  5. Analyze the data
  6. Report results

(see Fig. 3.1 on page 39)

Base your definition on a verb that has an outcome – identify, evaluate, etc.

Your problem will point you to a style of research.

Research plan:

  • problem statement
  • duration
  • who is performing what roles
  • how to target and recruit
  • incentive, tools and materials

Perform a screener to test possible participants – a simple survey that identifies:

  • what are specific behaviors
  • Level of tool knowledge and access
  • what knowledge of the topic do they need?

*Usability testing is necessary, but not always sufficient*
It provides you with a story, predicts what may or may not be successful, pre Q&A testing, identifies which user tasks are important.

Good participants, good facilitation and good analysis is important – not a perfect usability lab setup. Real life isn’t conducted in a lab!

Analyze the data:

  • Look for meaningful data
  • Turn into observations, which will then turn into
  • Recommendations

Chapter 4¬†–¬†Organizational Research

User-centered design considers client stakeholders part of the standard requirements.

Asking the same questions of different people will lead to understanding differences in motivation and understanding.

A stakeholder is a group without whose support the organization would cease to exists. Plan to:

  • Neutralize politics (yeah, right)
  • Understand priorities within organization
  • Tailor the process to work methods
  • Technical & business requirements
  • Getting buy in
  • Understanding how your work affects the organization
  • Understanding the workflow

Interviewing stakeholders:

  • Set agenda and send a few key questions ahead of time.
  • Good questions on page 67 & 68
  • Document attitude and they see as goal

Business requirement – a clear statement of what success will look like. What the doc should look like:

  • Problem statement
  • Gather ALL of the goals
  • Success metrics
  • Completion critera
  • Scope (boundaries). Note what is OUT of scope.
  • Risk, concerns, contingency plans
  • Workflow diagram
  • Add verbatim quotes for impact!




Print Friendly, PDF & Email

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>