Presented at the WordPress DC Meetup on 5/17/2011 Anthony Paul of Fathom Creative will be reprising and expanding on his very successful April lightning talk on defining requirements for your next CMS project. He'll be going into more depth on specific tools, approaches and processes surrounding the requirements gathering and definition for your next CMS project. This includes design, technical and content specification as well as shaping the ideal user experience. Anthony Paul is technical lead and user experience designer at Fathom Creative. Follow him on Twitter, @anthonydpaul.

1. Defining requirements for
your next CMS project
> Anthony D Paul

2. Who am I…
› Technical lead at Fathom (end-to-end; 5 years)
› User experience developer
› @anthonydpaul

3. What we'll talk about
› High-level design process (refresher)
› Focus on requirements definition
(importance, context, parts)
› Specific tools and methodologies
(purpose, pros/cons, samples)
› Case study
› Determining tools for you

4. Theory behind the design process
Behavior = function(Person, Environment)
› No control over the person
› Can identify the behavior
› Simply build environment that elicits the
desired behavior, right?
Lewin’s Equation

5. The more we know
about our users, the
more likely we are to
meet their needs.

6. High-level interactive process
Requirements
Definition
(info gathering,
specification
Production
(design,
development)
Delivery
(training, launch,
maintenance)
Testing

7. High-level interactive process
Production
(design, development)
Delivery
(training, launch,
maintenance)

8. High-level interactive process
Requirements
Definition
(info gathering,
specification
Production
(design,
development)
Delivery
(training, launch,
maintenance)
Testing

9. Foundation of the end product
Design
Local Architecture
Global Architecture
Functionality
Objectives (users, business)
TANGIBLE
ABSTRACT
Derived from: Jesse James Garrett’s "The Elements of User Experience"

10. What does that path look like?
Derived from: Liz Sanders’ "Co-Creation"
What it
ends up being
What it
could be

11. What does that path look like?
What it
could be
Derived from: Liz Sanders’ "Co-Creation"

12. Foundation of the end product
Design
Local Architecture
Global Architecture
Functionality
Objectives (users, business)
TANGIBLE
ABSTRACT

13. 3 main components
Requirements
Definition
Audit Processing Spec

14. 3 main components
Requirements
Definition
Ask
Audit
Think
Processing
Do
Spec

15. So, what do these break down into?
Ask
Audit
Think
Processin
g
Do
Spec
› (Objectives)
› Wants & needs (user vs. client)
› Climate (competition & market)
› Content
› (Functionality)
› Stories (humanity)
› Behaviors ($$$)
› Global arch. (taxonomy)
› Local arch. (hierarchy)
› Design

16. Tools we use to define them
Ask
Audit
Think
Processin
g
Do
Spec
Component Tools
› (Objectives)
› Wants & needs (user vs. client)
› Climate (competition & market)
› Content
› (Functionality)
› Stories (humanity)
› Behaviors ($$$)
› Global arch. (taxonomy)
› Local arch. (hierarchy)
› Design
› Surveys & interviews
› Card sorting
› Make tools (paper
prototypes & collages)
› Personas
› Usage scenarios
(task flows)
› Mood board
› Sitemap
› Wireframes
› A/B tests
› Digital prototypes

17. Card sort
› Purpose Determines high-level categorization preferences
› Method Stacks of paper, sticky notes, 3x5 cards (allowing write-ins)
› Analysis Put results into outline form or clouds
› Strengths Simple, cheap, quick, fun, foundational
› Weaknesses Content-centric (not tasks), may vary,
surface characteristics (not use)

18. Card sort

19. Card sort

20. Make tools
› Purpose Determine emotional needs, sometimes functionality
› Method Kit of materials, words, pictures
› Analysis Notes for inspiration, tabulated
› Strengths Easy, fun, high user involvement, candid
› Weaknesses Time consuming, hard to analyze, somewhat expensive

21. Make tools

22. Make tools

23. Personas
› Purpose Confirm understanding of users (notes for an exam)
› Method Write a story, add photo, name, motivations, etc.
› Analysis N/A
› Strengths Central reference encourages role-playing, fun, cheap
› Weaknesses Somewhat difficult, not quick, contains assumptions

24. Personas

25. Personas

26. Usage scenarios
› Purpose Maps personas to objectives, walks through
step-by-step actions
› Method Write ideal (but real) task flows, identify entrances & exits
› Analysis Identify patterns across users, prioritize
› Strengths Effective for common actions, auditable
› Weaknesses Somewhat difficult, not quick, contains assumptions

27. Usage scenarios

28. Usage scenarios

29. Mood board
› Purpose High-level look and feel pre-design
› Method Assemble colors, textures, photos, typefaces,
adjectives, screenshots
› Analysis N/A
› Strengths Clear communication, focuses designers,
puts users and brand in sync, auditable
› Weaknesses Somewhat abstract

30. Mood board

31. Mood board

32. Sitemap (& task flow)
› Purpose High-level taxonomy, task flows, navigation
› Method Treed map of content (not necessarily pages)
› Analysis N/A
› Strengths Organized for production, gives scope, auditable
› Weaknesses Overwhelming for clients, difficult to strike balance of info

33. Sitemap (& task flow)

34. Sitemap (& task flow)

35. Wireframes
› Purpose Local hierarchy, audit
› Method Non-designed layout of each page
› Analysis N/A
› Strengths First visual, tangible, controls scope, testable
› Weaknesses Difficult to balance design vs. utility,
sometimes requires many pages

36. Wireframes

37. Wireframes

38. A/B tests
› Purpose Prove success of specific deliverable
› Method Compare two or more versions (isolation vs. side-by-side)
› Analysis Scored and tabulated
› Strengths Definitive and arguable, quick, easy
› Weaknesses Limited to options, can be difficult to assemble/coordinate

39. A/B tests

40. Digital prototype
› Purpose Prove system before design
› Method Build site without design (entire or partial)
› Analysis Task assignments, testing protocols, bug tracker
› Strengths Both quantity and quality, closest to end product, relevant
› Weaknesses Expensive if discarded, similar to wireframes can be
hard to explain utility vs. design

41. Digital prototype

42. Digital prototype

43. Case study
› International student
organization
› Composted content
› Brand new messaging

44. Biggest challenges
› Content audit
› Many stakeholders/users
› Sitemap

46. As a testament to the newly
organized and optimized content,
one month after launch saw a
1200% increase in average daily
page hits (previously averaging
1,200/day, now reaching more
than 30,000/day).

47. Determining your tools
› Project size (budget)
› Personal preference
› Client need & risk

48. @anthonydpaul