A presentation from Museums and the Web 2009.
Maybe you’re supposed to overhaul your institution’s Web site. Or maybe you’ve been directed to visualize and implement new on-line initiatives. Other than knowing your stakeholders’ wish lists and extensive ideas for Web site content and features – from blogs to on-line collections – you don’t have a clear plan of action. You don’t even have a defense strategy for why or why not to invest in some of their requests. How, then, can your team drive decision-making? How can you get features implemented based on rational reasons, while balancing institutional goals and audience needs – all without going over budget? This mini-workshop will focus on an often-overlooked core Web site activity: the Feature Prioritization Workshop. You will be introduced to prioritization techniques and tools, how and when to use them, methods for navigating the myriad needs and wants of stakeholders, and some approaches for achieving compromise. You will learn to balance “requirements” with “desires” by using concrete proof points and a convincing defense. And you will also learn about building a phased roadmap that will accommodate the immediate needs of your organization at launch, yet will provide a plan for future iterations and builds.
Mini-Workshop: Redesign: Prioritizing [Mini-Workshop]
Assure Ecommerce and Retail Operations Uptime with ThousandEyes
Renee Anderson, Techniques for prioritizing, road-mapping, and staffing your web site: a feature prioritization primer
1. useums and the Web 2009
echniques for prioritizing, road-mapping, and staffing your web site:
feature prioritization primer
2. hat we’ll do today
. Introduction
I. Define what a feature is
II. Why and when to prioritize features
V. Analyze a couple of features together (10 minutes)
. Break into groups and prioritize the features (20 minutes)
I. Reconvene and share decisions (10 minutes)
3. hat is a feature, when it’s on a web site?
1. Something self-contained and interactive:
• A simple tool
• A widget
• A module, or part of a module, that displays stuff
4. hat is a feature, when it’s on a web site?
simple tool: adding specific content to your calendar, or sharing content
n Facebook (or Digg, or del.icio.us)
5. hat is a feature, when it’s on a web site?
A widget: a poll that dynamically displays your vote
6. hat is a feature, when it’s on a web site?
module, or part of a module: interactive areas of site pages, sometimes
ith sub-sections, with its own unique content and/or functionality
7. his is also a feature
2. Search: it’s actually a large set of sub-features
• The interface (simple vs. advanced? What are the most important facets?
• The results (what order do they appear in? how many will display on eac
page?)
• Manipulating the results (are they sortable? filterable?)
• The metadata (how are the results categorized and mapped to the web s
as a whole?)
• The post-search (can a user save their results, or share them with someon
• SEO (how will my stuff display in Google, and do I need to create optimiz
landing pages?)
12. hese should be considered features
3. Content is no longer static
• Digital media: a video, a podcast, or an interactive contained experience
• User generated: Uploaded photos, comments, projects and groups
• Dynamic: auto-generated based on rules and categories
13. o really, “feature” is just a fancy name for all the
tuff you can see on a web site.
14. o how do you prioritize all this stuff?
eature prioritization is a method for balancing multiple
nputs from different groups of people, elevating the useful
nd important features while pushing back irrelevant or overly
omplicated ideas.
Stakeholders Users Engineers
15. he most important aspect is...
..getting representatives from these three groups in the same
oom, discussing and debating features and content and
istening to each other.
Stakeholders Users Engineers
16. hen should it be done?
•Early!
•Before committing to any design ideas
•Ideally, after thinking through how some of the stuff might work
17. ow is it done? It’s about ranking.
From a stakeholder perspective, important items
are ranked high, and less important items are
ranked lower.
Stakeholders
Questions to consider:
•Will a feature support the institution’s mission?
•Will a feature support new or existing initiatives?
•Will a feature elevate the institution’s brand or
outward communications?
•Will a feature improve internal workflow?
18. ow is it done? It’s about ranking.
From a user perspective, desirable and useful ite
are ranked high, and less desirable or useful items
are ranked lower.
Users
Questions to consider:
•Will a feature solve a user’s problem?
•Will a feature add value to the user?
•Will a feature make something easier to use or d
on the site?
•Will a feature enhance your audience’s relationsh
to the institution?
19. ow is it done? It’s about ranking.
From an engineer’s perspective, easy and quick
to implement items are ranked high.
Hard to implement (or time consuming) items ar
Engineers
ranked low.
Questions to consider:
•Is a feature supported by your existing technical
environment?
•How much training will be involved?
•What contingencies need to be in place for the
feature to work?
•How much customization is involved, and how
will this be affected when upgrading?
•Are there open source and free services already
20. hat does ranking end up looking like?
e often use the following very simple scale (remember, this is NO
cientific and doesn’t pretend to be):
•Institutional importance: 5=high, 1=low
•Audience importance: 5=high, 1=low
•Technical implementation: 5=simple, 1=difficult
So when tackling your new search feature set, sub-features may e
up looking like this:
Feature Name Institutional Rank Audience Rank Technical Rank Average
Simple keyword search 5 5 4 (4+5+2) / 3 = 4.
Auto-suggest terms and 4 5 1 (4+5+1) / 3 = 3.
phrases (like Google)
21. eature #1:
collection
www.dominomag.com)
Controlled and owned by logged-in
ember
Clippings of images from articles
Categorizing into folders
Adding notes and tags
Sharing with friends
22. eature #1:
collection
www.flickr.com)
Photo collections mapped to physical
ocations
Dynamic pages generated from site-
ide member uploads
View by “interestingness” or time
Acts as a hub for all people, photos,
ags, and content related to that
ocation
23. rainstorm: What features could be in a museum
nline collection?
• Interactive
• Sets of related sub-features
• Content
24. eature #2:
calendar
www.google.com)
Looks like a calendar!
Make public or private
Import other Google
alendars into interface
Export to other
alendar programs
Different views (day,
eek, month)
25. eature #2:
calendar
www.flickr.com)
Integrate images into a
ypical calendar view
Based on popularity
“interestingness”) for
ny particular day
Supports exploration
ver usefulness
26. eature #2:
calendar
www.istanbulmodern.org/en/f_index.html)
Unusual layout in
imeline format
Acts as site navigation
Sub-grouped by event
ype
27. rainstorm #2: What features could be in a
useum’s calendar of programs and events?
• Interactive
• Sets of related sub-features
• Content
28. reak into smaller groups
ou will represent:
Stakeholders
Users
Engineers
ick one of the feature sets:
Online collection
Calendar
rioritize the features using the worksheet I’ve given you.
ome back as a group and share some of the thinking.
29. hank you! Hot Studio, Inc.
585 Howard Street, 1st Floor 5 Union Square West, 4
San Francisco, California 94105 New York, New York 10
415.284.7250 212.242.1082