This is the fun part, defining what the website should do.
With all the knowwledge acquired up until now, it should be possible to make a list of functionalities you will need for your website, based on what your visitors expect.
First part of making this list is defining the basic requirements for the website. They're scentences telling what the website should do and not do. It's about the central idea of what you offer on the website, the customer value proposition. you should be able to continue the scentence with a "because the user wants/needs ....."
An example for an ecommerce site:
"A functionality of the website is to have a product search, because the user wants to find what he needs quickly."
Then you can define the secondary requirements, those that eliminate barriers. They can be functionalities or non functional requirements, we can use the scorecard to already name most of them, based on the webscorecard goals.
"A functionality of the website is to have Https , because the user wants to be able to trust the website."
Other site functionalities on webmaster level can be the defined like the need for user or content management.
"A functionality of the website is to be able to do a-b testing, because the webmanster has to be able to continuously improve the website."
With some imagination you should be able to name the activities around the website after going live and may indicate even more requirements based on that exepected use.
Next we need to know the content in the website, wat will the user want to read and what does the business want to offer?
Here also we should be able to connect content to a goal related to the customer or other stakeholders
"The website should containt an about us page , because wants to be able to trust the website."
What also should be done is to get from the webscorecard the management requirements for the site, a first definition of the desired webanalitics functions.
"The website should deliver data about number of bounces on productpages, because this is an signal of a barrier on the website."
"The website should deliver data about number of targeted keywords on first page in Google, because this is a indicator for number of visitors on the website."
These functionalities and requirements should all be put in a list, together with one more list of requirements, those needed for elimitating the barriers. The findability and trust barriers are important to get clear, before starting to setup structure, designs and mockups .
After knowing what the requirements are, a navigation schema for the website should be drawn.
Based on the navigation scheme, mockups of the site can be made with the different functionalities. The site comes to life now, and it's already possible to test a bit. For the best results, content should already be written and developed in this phase, as content can have impact on construction of the site.
After defining more detailed content and funtionalities of the website, and creating a prototype, we should not forget to go back to the scorecard and check if all goals are covered by requirements, functionalities and content. The prototype with content will give you something you can be really critical about, trying to see how to improve that. Next to the visible goals there are the invisible goals we should keep in mind
For example you do not want to think about optimizing your site after having the first version of your site in the air, because it's simply too late. It's not only about content and some html tricks, but also may affect the way things are programmed.
A seo-optimized site should be a basic requirement.
Accessability is also a topic to be discussed for the same reason. Accessability is partly about giving access to blind an deaf people, partly about what browser types you will support. That is not only a choice of versions of firefox and internet explorer, but also about what mobile devices you will consider.
All the barriers have their own aspects and characteristics, and technical implications. The more you can learn about them, the better your can decide what is needed and not when defining what should be in the site before the launch.
After this it's time to freeze it all, and get things build.