Overview
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.
A Little Background
I work at a user-centered design agency in San Francisco called Hot Studio. We’ve been around for more than 10 years, and throughout this time have had the pleasure of working on hundreds of Web sites for many clients, both large and small, non-profit to Fortune 500. Sometimes we do complete redesigns, sometimes we do brand new sites, and sometimes we focus on redesigning parts of existing sites. In all cases, we rely heavily on our clients to be subject matter experts: for example, people working at a bank will know far more about financials than we will.
Our area of expertise, other than in actual design methods and principles, is in uncovering our clients’ audiences’ motivations and desires. We do this through extensive research, be it new research that we conduct ourselves, or existing research our clients provide for us. Usually it is a combination of both. During this process we uncover plenty of ideas of what the Website should do, and what content it should have on it, ideas that come from stakeholders and from users. On a parallel track, we are informing and sharing the ideas with the project engineers so they are aware of what items we recommend should be built, and how we’re thinking about designing them.
More often than not, stakeholder requirements and requests, user needs, and technical parameters are not in synch. We usually uncover far too many potential features and content items that can be created within the project timeframe, or the budget doesn’t support the entire list, or there isn’t enough staff to do the work. This is where prioritizing becomes required to move forward with the project. It is also a great method to gain consensus with stakeholders.
What is a Feature? And Where Does Content Fit?
A feature in the world of software can be defined as “a capability.” In the world of Web sites, we tend to think of features as tools, components, widgets, or some other self-contained interactive thing where a user can do something. A video is a feature. RSS feeds are features. An interactive flash marketing campaign is a feature. A comment input field is a feature.
What about something bigger and more complicated, like site search and results? And aren’t the results content rather than a feature? And what about requirements?
Again, in the world of software, engineers got it right when deconstructing something big into its discreet parts, and prioritizing based on the parts, not just the single multi-faceted feature. Complicated features are often referred to as feature-sets, and broken out into separate sub-features. For example, in order to build search, it’s not only about the end-user interface and the supporting back end. It’s about metadata, SEO, content types, the amount and type of information to show in results, what order the results should be displayed in, whether the results can be sorted or filtered, if the user can save the results or even the initial search criteria…it can go on and on.
Looking at this search example, it gets pretty tricky to distinguish between what is defined as a “feature” and what is defined as “content,” while somehow including requirements in all of this. We actually don’t think it’s necessary on Web sites, especially functional sites, to make distinctions among these in order to prioritize them. Actually, by including “content” when prioritizing, we make sure that all bases are covered when determining if the necessary resources exist. Who is going to WRITE this stuff, let alone build it?
What is Feature Prioritization?
Simply stated, it’s a method for balancing multiple inputs from multiple groups, elevating the useful and important, and pushing back irrelevant or perhaps overly complicated ideas. Prioritizing features and content can be tackled in a variety of ways, but first and foremost, it is not a scientific method. Think about it as ranking features and content, and then sorting the features and content from highest ranked to lowest ranked. Those ranked highest should be considered in scope for your Web site.
When prioritizing features and content, it’s common to end up with some parts of a complex feature-set (search) being highly ranked, and some parts ranking lower. The higher ranked parts can still be considered for launch while lower ranked parts can be added in later in a phased project plan.
Simple, right?
Why Do It in a Workshop?
It isn’t really that simple. It’s a simple method to grasp, to rally around and use internally, but the process of ranking can be tricky. The most important component of the workshop is to invite the right people.
Representatives of an institution (stakeholders), representatives of the institution’s technical environment, and representatives of the institution’s users (usually these are your design or Web team) need to be involved. When Hot conducts these workshops with our clients, we always play the role of the user. These three representatives need to rank each of the features and content from their perspective. Will it benefit the institution? How easy or hard is it to build (or how long will it take)? Does your audience really care about it? Getting the right people in the same room discussing each feature from these respective views, while time-consuming, is invaluable for achieving consensus with a collective understanding of constraints.
In many cases the engineering team will need further discussion and more detailed definition to be able to scope features. We always expect to spend more time with the representatives to explain design ideas, and we take care to compromise. We need to understand the constraints of the Web site back-end, and quite often we can’t make extreme (let alone subtle) changes to some core functionality.
Why Involve the Audience Point of View?
Cultural institutions have fairly demanding audiences. They have high expectations. One of the many challenges is to create in-person programs and experiences that go beyond audience expectations, that surprise them and perhaps even transform them. In these cases, we must make decisions that may be influenced by audience feedback but certainly isn’t always dictated by them.
When it comes to an institution’s Web site, how far should we translate the in-person experience to this on-line medium? What are the basic necessities that the audience needs from the Web site, what can enrich their on-line visit, and what would go beyond their expectations? Again, in some cases we may not choose to heed direct feedback found through research, but in many cases, the audience knows what they need from the Web site better than we do.
Inviting this third point of view into the mix, balancing the institution’s point of view and the technical point of view, often brings clarity to internal conflicting priorities.
Consider the following questions:
- Is the feature or content solving the audience’s problem?
- Is it adding value?
- Is it making something easier to use or do?
- Is it enhancing their relationship to the institution?
When Should It be Done?
From Hot’s perspective, a feature prioritization workshop takes place after some design thinking has taken place. Note that I’ve said design THINKING, not design commitment.
We’ve already conducted research, and we have an understanding of institutional requirements and vision, user needs, and the technical landscape. We’ve begun planning how the site will be organized, drawn out the tasks that people need to be able to do, and how some pages might be structured. We have begun sketching out some functionality.
We have not begun applying any visual design. In fact, we haven’t even begun to finalize any aspect of the design. This is pre-design, the strategy phase, where we’re coming up with the big ideas that can solve the problems that our research has surfaced.
So why conduct the workshop at this point, and not when we’re doing the actual design? Because by the time we’ve begun designing, we’ve committed to the way the site is structured, how the content is organized, and how the features work; but we may not have understood the technical ramifications involved in building the site this way. Or we may not know that one of the pages we’ve focused on is far less important to the institution than a different page. Or that simply because in our research the target audiences seemed really excited about a particular feature, we find out later that it doesn’t align to institutional goals. It can be very difficult to back-track at this point.
Remember: Web sites aren’t cookie-cutter, features are never generic, and content is never final. As we go through strategy, we will find that we need to add components or functionality, or that some new content needs to be written, or that what we thought was easy to build isn’t. Defining features and content before designing them is of utmost importance. What we think may be simple at first can end up becoming complex as we think through how someone might use it, and it’s vital to keep the team informed of evolving ideas.
A feature prioritization workshop is a collaborative method of bringing everyone up to date, and involving them in the decision-making process.
What is the Outcome?
Each feature in your list will have a different ranking by the institution, by the user, and by technology. A simple ranking method is as follows:
- Institutional importance: 5=high, 1=low
- Audience importance: 5=high, 1=low
- Technical implementation: 5=simple, 1=difficult
A feature might be ranked the following way:
| Feature name | Institutional rank | User rank | Technical rank | Average |
|---|---|---|---|---|
Buy tickets online |
4 |
5 |
2 |
(4+5+2) / 3= 3.66 |
After ranking and sorting the results, the highest ranked features and content will float to the top of the list, some will move to the middle, and some will be ranked fairly low. In a perfect world, the highest ranked items can be what you focus on for your site launch, the middle tier gets moved to phase two, and the bottom ranked items get moved to the future or even get cut altogether.
While I would like to suggest it’s this straightforward (again, sorry), there are two common and important considerations that can affect this tidy outcome:
- stakeholders reemerge
- future resources need to be considered (staffing, maintenance, additional technical systems…).
In the end, it’s really up to the institution whether a feature is implemented or not, regardless of how it is ranked overall. The institution may override the low technical ranking and require that the new site include on-line ticket purchasing; in which case the team needs to figure out how to keep it in scope.
Additionally, an on-line ticketing system may have never been considered when budgeting for your Website design project. So while it may be ranked as important and valuable, the cost is deemed prohibitive for launch, so it gets pushed to phase two after the institution receives additional funding.
Conclusion
One of those most valuable aspects of a feature prioritization workshop is the involvement of key decision-makers, in the same room, setting priorities in a group environment. While it can be time consuming, often requiring further meetings and discussion, in the end we emerge with consensus and a plan of action. Compromise and tradeoffs are inevitable, but the right people are making hard choices as a group.
Timing is important. Doing this workshop after the design thinking and before design commitment offers two key benefits:
- We will already have a sense of how we want the site to be organized, how some of the big ideas play out, and what the key interactions will be. All can help participants understand how features might work and what content may need to be created – knowledge that can only benefit the ranking process.
- We haven’t committed to detailed design. So if we find out that an idea is too complicated or deemed unnecessary, we haven’t yet invested a lot of time and resources into an idea that ends up being excluded from the project plan.
In the end, all of this work is worth the effort. It will pay off in the long run – especially since all of the decisions are now defendable: the whole team is in alignment about priorities, and this means the Web site design will ultimately reflect these priorities.
Further Reading
Calligaro, Mike (2007). “On the Left Hand: How Feature Prioritization Happens.” Windows Mobile Team Blog, http://blogs.msdn.com/windowsmobile/archive/2007/06/05/on-the-left-hand-how-feature-prioritization-happens.aspx
Khan, Saeed (2005). “A Model for Metrics-Driven Feature Prioritization.” pragmaticmarketing.com, http://www.pragmaticmarketing.com/publications/magazine/3/3/0505sk
Nandakumar, Vinodh (2008). “Maximizing product value by effective feature prioritization.” techcruising.com, Making Better Products, http://techcruising.wordpress.com/2008/05/15/maximizing-product-value-by-effective-feature-prioritization/
Polansky, Adam (2007). “Faceted Feature Analysis.” boxesandarrows.com, http://www.boxesandarrows.com/view/faceted-feature#comment_10358
Sabat, Tim (2008). “On Prioritizing Feature Development.” particletree.com, http://particletree.com/notebook/on-prioritizing-feature-development/
Wiegers, Karl E. (1999). “First Things First: Prioritizing Requirements.” processimpact.com http://www.processimpact.com/articles/prioritizing.html
