Let's take another look at the Pasadena Conservatory project for a real-world example.
Here again is the list of user and client needs that came out of the strategy phase.
Let me highlight a few of them to explain how these needs were
translated into requirements for content and functionality.
The user need to know who's on the faculty,
can be simply answered with a list of
all faculty members and having bios for each teacher will be helpful too.
But since the list is rather long,
we decided to also implement filtering functionality.
The user can filter all faculty members by the instrument they teach.
We also made the list searchable via a search function.
Another user need was to question what instruments are available?
Content that addresses this would include a list of
all instruments that are being taught and information for each.
We decided that we would also design a set of icons
for each instrument to make the site more unique.
On the functionality side,
one could imagine a fun quiz that asks the user a series of
questions and in the end suggests what instrument they should learn.
This would be especially appropriate if our strategy also determined that
many parents are unsure what instruments their children should study.
Alas this is not something we actually built.
Remember the feasibility constraints one also needs to consider.
Building such a tool would be quite involved and will take additional time and resources.
One of the client needs was to promote events.
So, for content, we'll obviously need information about the events.
But we also need a way for people to order tickets,
that goes into the functionality column.
But a ticket ordering system represents quite some complexity,
you will need to build a shopping cart, process payments,
facilitate account creation, login functionality, and password recovery.
So, we decided we would use an external service for ticket purchases.
A service like Eventbrite or Brown Paper Tickets.
The downside of using an external service is of course that you are taking the user
away from your site and you're interrupting the seamless flow of their experience.
But the upside is,
that you will rely on someone having figured out all the complexities of selling tickets.
It's a compromise for sure and in this case we
determined that it made sense to use an external service.
The client also wanted to employ photography prominently throughout the site,
well obviously, then we'll need great photography.
At this point, it's important to remind the client
that if such photography doesn't already exist,
it's high time to hire a photographer.
Later on when we're designing the visual appearance of the site,
we will need these images.
Another needs of the client was to demonstrate community,
while as content we'll need images and stories that
talk about how the conservatory fosters community.
As functionality we determined that a blog would be
a good way to provide users access to these stories.
A blog requires many additional functionality considerations.
We decided that we would have the ability to filter their blog posts by categories.
As a side note that meant that we would have to eventually choose a list of
appropriate categories but this is best addressed in the next phase, the sitemap phase.
We also decided that the posts would always be sorted by date in
descending order so that the latest blog posts will show up first.
We discussed the possibility of giving users the ability to leave
comments but comments bring up another host of questions to resolve,
would users be able to leave comments anonymously or would they have to be logged in?
The latter would require us to build a way for users to create accounts.
Also, who will check the comments for
their appropriateness in terms of language and content?
How do we prevent trolls or
advertising spam on the opposite end of the problem spectrum was this question,
would people even want to leave comments in the first place?
A blog with no comments at all is a very sad place.
So, ultimately, we decided against implementing comments.
Lastly, I want to point out that you'll encounter needs
that cannot be easily fulfilled by content or functionality.
Take for example the client need of creating an attractive and memorable website,
this need will be most fully answered in the last phase,
the visual mockup phase.
So, in the end,
you will list all content and functionality requirements in two lists.
This represents your outline of scope.