Gathering and Defining Requirements for Your Next CMS Project

Defining requirements for your next CMS project

> Anthony D Paul

› Technical lead at Fathom (end-to-end; 5 years)

› User experience developer

› @anthonydpaul

Who am I…

› 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

What we'll talk about

Theory behind the design process

Lewin’s Equation

Behavior = function(Person, Environment)

› Simply build environment that elicits the desired behavior, right?

› Can identify the behavior

› No control over the person

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

High-level interactive process

RequirementsDefinition

(info gathering, specification

Production(design,

development)

Delivery(training, launch,

maintenance)

Testing


Production(design, development)


maintenance)



(info gathering, specification

Production(design,

development)


maintenance)

Testing

Foundation of the end product

Derived from: Jesse James Garrett’s "The Elements of User Experience"

Design

Local Architecture

Global Architecture

Functionality

Objectives (users, business)

TANGIBLE

ABSTRACT

What does that path look like?

Derived from: Liz Sanders’ "Co-Creation"

What itends up being

What itcould be

What does that path look like?

Derived from: Liz Sanders’ "Co-Creation"

What itcould be

Foundation of the end product

Design

Local Architecture

Global Architecture

Functionality

Objectives (users, business)

TANGIBLE

ABSTRACT

3 main components


Audit Processing Spec

3 main components


AskAudit

ThinkProcessing

DoSpec

So, what do these break down into?

AskAudit

ThinkProcessin

g

DoSpec

› (Objectives)

› Wants & needs (user vs. client)

› Climate (competition & market)

› Content

› (Functionality)

› Stories (humanity)

› Behaviors ($$$)

› Global arch. (taxonomy)

› Local arch. (hierarchy)

› Design

Tools we use to define them

AskAudit

ThinkProcessin

g

DoSpec

› (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

Component Tools

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)

Card sort

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

Make tools

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

Personas

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

Usage scenarios

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

Mood board

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

Sitemap (& task flow)

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

Wireframes

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

A/B tests

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

Digital prototype

Case study

› International student organization

› Composted content

› Brand new messaging

Biggest challenges

› Content audit

› Many stakeholders/users

› Sitemap

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).

Determining your tools

› Project size (budget)

› Personal preference

› Client need & risk

@anthonydpaul

Gathering and Defining Requirements for Your Next CMS Project

Design

Transcript of Gathering and Defining Requirements for Your Next CMS Project