5. Hi-fi / Absolute. Are we nit-picking?
No.
There are real differences
between rogue and traditional
6. Requirements are vague, systems are specific.
Don’t let anyone think we can defer making decisions.
Every correction made during development is costly.
Where traditional says
“We have a few
concepts…
(now relax!)”
Rogue-UX says
“There is only one
working model…
(now fight!)”
7. For every “A” & “B”, there are an infinite number of “C”s.
A/B tests should be for final evidence.
Where traditional
MIGHT say
“We’ll A/B test,
and let the
customer decide”
Rogue-UX says
“A/B tests are for
proof, not
decisions”
8. What you see in the working model will be in the real
system, unless you specify otherwise. Today.
Where traditional says
“It’s just a
mockup”
Rogue-UX says
“This is real”
9. Is it important? (Hint: YES)
1. Companies with poor feature analysis will have three times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright failure than a success due to
the way they approach business analysis. In fact, 50% of the group's projects were "runaways" which
had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated
budget; or delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when they use poor requirements
practices on their projects.
4. Over 41% of the IT development budget for software, staff and external professional services will be
consumed by poor requirements at the average company using average analysts versus the optimal
organization.
The Impact of Business Requirements on the Success of Technology Projects, IAG 2008
11. 3 new things I learned
1
Lo Fi is still
required
Don’t skip the sketchy, loose
ideation phase.
Balsamiq is a great option
here.
2 The tools are the
rules
Since there is only the
browser (not any ‘player’), all
forms of interaction are fair
game.
That makes for great
customer testing.
3 Narrow in on
perfection
There is a natural ‘core screen’
on every app, but don’t go
deep on one aspect. Rather,
model the whole process
broadly, then refine.
Don’t even try to document
until at least round 3, 4 or the
final showcase. Things change.