Content Management Systems gives you a huge tool box to deliver features. As CMSs accelerates the development cycle, the question changes from “How do we build sites?” to “What should we build?” This session presents the strategies and methodologies we have learned and used over the last 12 years to build results driven websites.
For decades the gold standard for measuring project success has been the project management iron triangle: on time, on budget, on scope. Despite increasingly more rigorous planning strategies, the average project is still 45% over budget, delayed by 63% and missing 1/3 of the promised functionality.
Worse yet, this obsession with certainty is reducing quality, innovation and value while burning out web development teams - and things are only getting more difficult.
A new way of thinking is needed to build truly successful projects. This session presents modern strategies and methodologies that have continually proven to beat the averages. We will review the latest research and advice from the world’s foremost software engineers. The session will conclude with a breakdown of the innovative methodologies that drive the majority of the world’s leading websites.
This session is for anyone looking to build more successful projects. Project owners will learn how to drive innovation, faster and with less cost. Your development team will learn how to continually deliver better work with less stress and long weekends.
Building Results Oriented Websites: The Method That Ends the Madness
1. Nov 19, 2011 Building results-oriented web projects
[MM.DD..YY] [PRESENTER]
Building Results
Oriented Websites:
The Method that
Ends the Madness flickr.com/photos/cuppini/2719863711
2. Why do we plan?
Stakeholder utility
• Look and feel
• Features
Certainty
• On time
• On budget
• In Scope
End user utility
• Emotional branding
• Content
• Features
• Usability & Experience
Organizational returns
• Increased revenue
• Reduced cost
• Increased goodwill
3. 5 years from now
A B C
Features
Certainty
User delight
Org. value
4. What is a results oriented website
flickr.com/photos/ncreedplayer/5403123930 flickr.com/photos/masoncooper/456641277
5. Why should we plan?
1. Maximize
organizational returns
returns
2. Optimize user user
experience experience
3. Reduce waste
stakeholder
utility
certainty
waste
6. Traditional web development process
• Concept
• High-level requirements
Requirements • Requirements gathering
• Requirements spec
planning
• Product (UI) Design
• Wireframes
Design • Detailed Design
• Functional specs
• Creative design
Implementation • Content
• Development
development
• Unit testing
Verification • Acceptance testing
• Beta testing
live Maintenance
7. Big Design Up Front
6 months
returns
user
$ experience
stakeholder
utility
certainty
waste
8. Mid Design Up Front
6 weeks
returns
user
experience
$
stakeholder
utility
certainty
waste
10. The McCracken Uncertainty Principle
The higher the feature velocity of a
project, the less precise the
resources needed can be predicted
11. Planning for certainty
=
certainty no long
term value
=
certainty waste
source: blogs.msdn.com/b/dannawi/archive/2009/05/15/2009-standish-chaos-report-we-are-successful-in-the-failure.aspx
12. Getting what you want vs. knowing what you want
Freedom to innovate
=
certainty less value innovation
= $ Insight to innovate
value
more money time
high level design & mockups validation live
requirements architecture
13. Where to go
Mid DUF Big DUF Agile
certainty
value
waste
cost $ $ $
14. A better approach
waterfall agile
Requirements
website Requirements
features
6 months 2 weeks
Design Design
Implementation Implementation
Verification Verification
15. Project management methodologies comparison
Cowboy Agile Waterfall
Requirements Little formal Lightweight, Very formal Big
requirements structured Design Up Front
Owner - team Usually fixed bid, Typically fixed Initially fixed bid by
Agreements poorly defined budget or fixed stages. Modified by
scope. scope – value based change orders.
Owner – team Undefined Collaborative Contractual
relationship
Owner – team Whenever Cycle every 1-4 At major
communication weeks milestones. May be
months apart.
Improvement Whatever Discussed each Formal change
changes requests cycle – better ideas order process built
easily integrated to resist change
Risk management ??? Adaptive - by doing, Predictive – by
inspecting and planning
adapting
18. The plan
agile project more
management stuff
online
results
results oriented the
user-centered right
planning stuff
a.k.a more of the right stuff
19. Process
Models based
• Light weight
• Iterative
• Comprehendible by everyone
• Synchronization
• Collaboration
Types of models
• Results models
• User role models
• User stories
• Interface models
Participatory workshops
• Rapid
• Comprehensive
• Synergistic
• Consensus
20. Results modeling
Process
Definition: • Brainstorm
•
the benefits stakeholders
want to achieve with the Organize
site.
• Consolidate & refine
• Prioritize
22. Results modeling: brainstorm
increase bike The site should Reduce routine Staff should be
sales have a clean and customer call able to add and
professional look inquires by 50% edit content
become a Be more viral Sell more bike Expand our
recognized leader repair services digital footprint
in the local biking
community
Show the To increase Sell more bikes Get 500 “Likes”
pictorial history traffic to the site online on Facebook
of results bikes
The site should Increase bike Double our Visitors should be
be intuitive and rentals by 100% mailing list able to find what
easy to navigate they want in no
more than 3 clicks
23. Results modeling: organize
increase bike Increase bike The site should
sales rentals by 100% have a clean and
professional look
Sell more bikes
online
The site should
Reduce routine be intuitive and Show the
Sell more bike customer call easy to navigate pictorial history
repair services inquires by 50% Visitors should be of results bikes
able to find what
they want in no
more than 3 clicks
To increase Staff should be
become a able to add and
traffic to the site
recognized leader
edit content
in the local biking
community
Be more viral
Expand our Get 500 “Likes” Double our
digital footprint on Facebook mailing list
24. Results modeling: consolidate
Goals Objectives Valued events Features
Show the
increase bike To increase Increase bike
pictorial history
sales traffic to the site rentals by 100%
of results bikes
Staff should be
become a Sell more bike Reduce routine able to add and
recognized leader repair services customer call edit content
in the local biking inquires by 50%
community
The site should Sell more bikes Double our
be intuitive and online mailing list
easy to navigate
The site should Expand our Visitors should be
have a clean and digital footprint able to find what
professional look they want in no
more than 3 clicks
Be more viral Get 500 “Likes”
on Facebook
25. Results modeling: refine
Goals Objectives Valued events
increase bike Increase by sales Bike purchase
sales by 50% a month Value = 40% of
within 6 months the retail price
26. Results modeling: prioritize
Primary Secondary Tertiary
increase bike Expand our Be more viral
sales digital footprint
Sell more bike To increase Sell more bikes
repair services traffic to the site online
become a The site should The site should
recognized leader be intuitive and have a clean and
in the local biking easy to navigate professional look
community
27. User role modeling
Process
Definition: • Brainstorm
•
a collection of defining
attributes that characterize Organize
a population of users and
their goals, needs and
intended interaction with
• Consolidate & refine
the site
• Define
• Prioritize
28. User role modeling: brainstorm
local newspaper people from out bike shoppers job seekers
of town
sports blogger fans person who new mom/parent
wants to upgrade
their bike
website staff competitive rider casual bikers
administrator
hotels that need new bike rider bike owners tour guide
bikes for guests
29. User role modeling: organize
local newspaper person who staff
wants to upgrade
sports blogger their bike website
administrator
fans
bike shoppers
new mom/parent
job seekers
people from out
of town bike owners
hotels that need competitive rider
bikes for guests
casual bikers
tour guide
new bike rider
30. User role modeling: consolidate & refine
enthusiasts shoppers staff
local newspaper bike shoppers staff
sports blogger new mom/parent website
administrator
fans person who
wants to upgrade
their bike
renters owners job seekers
tour guide bike owners job seekers
people from out casual bikers
of town
new bike rider
hotels that need
bikes for guests competitive rider
31. User role modeling: define
Demographics
owners • Age: 25-55
• Gender: 65% male
• Location: within 10 miles of store
Psychographics
• Active lifestyle
• Prefers being outdoors
• Green
Behavioral
• Significant web usage including search engines and social media
• Research purchases online before buying
• Significant use of mobile devices
Brand
• Custom service is significant driver for brand loyalty
• Likely to buy again from same store. Typically 1 bike every 4 years.
Site
• Proficient web user
• Likely to have high speed internet access
33. User role modeling: prioritize
Primary Secondary Tertiary
shoppers enthusiasts job seekers
renters staff
owners
34. User stories
Definition:
Process
describes a features and
functionality of the site from • Brainstorm
• Organize & refine
the viewpoint of a user role
• Prioritize
36. User stories: format
As a [user role]
I want [a feature or goal]
so that [a benefit or reason]
* so that is optional
A user story is a documented
requirement and a note to discuss later
37. User stories: brainstorm
As a Bike Enthusiast, I would like to
• read the latest bike shop news/blog
• comment on the blog
• share content through email and social media
• see a calendar of events, classes, races
• sign up for newsletter and alerts
• see special offers
• get contact information
• see location and hours of operation
38. User stories: prioritize
MoSCoW approach
• Must haves – we need these stories in order to launch the
project
• Should haves – these are of high importance, but are not
show stoppers for the next release
• Could haves – If we get a couple of these in it would be
nice, but they can be moved easily to the next release
• Wants – These are not a priority but we want to keep track
of them as possibilities for future releases.
39. Interface models
Definition: Common interface models
graphical or organizational • Navigation architecture & maps
representation of site
elements and how they
• Content models
relate to each other • Wireframes and prototypes
• Design comps
41. Summary
1. Don’t obsess over certainty, you will
get more done.
2. Software is for the end users, get out
of your head and into theirs
3. It is about benefits, not features.
Results should be a continual focus.
42. all-in-one results oriented website
A results oriented website in a box*
*box not included
For organizations age 0 to 150
Super secret D7 version:
http://apps.leveltendesign.com
43. thank you!
Tom McCracken
LevelTen Interactive
Director
Phone: 214.887.8586
Email: tom@leveltendesign.com
Twitter: @levelten_tom
Blog: leveltendesign.com/blog/tom
LinkedIn: linkedin.com/in/tommccracken
Notas do Editor
Whenever I present I always like to get a feel for who is in the room.How many people here are owners of Drupal website?How many are builders of Drupal websites?How many are thinking about getting into Drupal?How many have done SEO on a Drupal site?How many people are new to Drupal SEO?How many people don’t even know what SEO is?
You might be saying wow that is a lot of planning. Why is it important to do that planning
So the question is how to you get to the top of the food chain?[do the speel]
So the question is how to you get to the top of the food chain?[do the speel]
There is a
So the question is how to you get to the top of the food chain?[do the speel]
All of this power and flexibility does come with a cost, Drupal can be very complex and comes with a learning curve. The Open Enterprise distribution greatly simplifies the common things businesses and organizations want to do with Drupal.
Install DAMP, import OE Core
This is how a traditional process for building a website. Or I should say, this is how a traditional website is supposed to be planned. Many larger sites are planned this way, but often to save cost steps might be skipped.
Our first web project at LevelTen back in 1999 was truly a big design up front. Planning took 6 months. Numerous meetings, interviews, surveys, user focus groups, wireframes, UML based functional specs.
Then then 2001 recession hit. People no longer wanted to spend six figures on project planning. The shift was on to compressed planning phases. I call this mid design up front. The primary focus of MDUF was quickly gathering the stakeholders requirements and engineering just enough to get a reasonable estimate for budgets and timelines.
So here is the typical project. Stakeholder recognizes that people like Facebook. Thinks, ah ha, what if we had a company extranet like Facebook, people would like us. Puts together a few pages of things facebook does, mashes in some linkedin, Twitter, and YouTube. Sends the project out for bit to a half dozen companies.
So how successful do you think these the big and midsized design up front process was at brining projects in on time, on budget, and in scope?[show slide]Pretty horrible. The average project is 45% over budget, 63% late and missing 1/3 of the originally promised features.…We already know that we are not getting long term value from the certainty we are generating. But it turns out that we are not even getting certainty. Which of course means we are spending time that is actually just a waste.
There is another significant problem with traditional waterfall processes. We force stakeholders to make the big decisions when they know the least amount about the best solution. So certainty also means that stakeholders get less of what they want.So how do we fix these problems? How do we get better certainty in our projects with more accurate estimates, understand better what the stakeholders want? More planning right?
Install DAMP, import OE Core
Agile processes are
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
There is a general perception that website requirements are something that exist somewhere out in the ethos and all we have to do is go out and gather them. The reality is that not all requirements are known at the beginning of a project. Most certainly not the best ways of build things is understood at the beginning of a project.The process we are going to use for rapid, light-weight requirements gathering is like trawling for fish. We start by casting out a wide net with a wide mesh. We are looking to quickly capture the big, most important requirements. We can then later use a finer mesh net to capture more detailed requirements.The important thing to remember is that agile requirements are not something that is done once at the beginning of a project and set in stone. The are revisited periodically throughout the project and iterated over. Don’t waste time adding details till just befom you really need it.Robertson and Robertson (1999) from User Stories Applied p 43
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.