
Communicating Website Functionality
As websites become more and more complex it becomes increasingly difficult to explain and document their functionality but, more than ever, the need to do so is critical. Accurately defining how a website operates informs stakeholders (those who have commissioned the site, either a client or in house) as well as developers.
Below I’ve listed nine techniques that you can use to describe functionality, and included the strengths and weaknesses of each.
Sketches
Don’t underestimate the power of the humble sketch. Through a rough “back of an envelope” sketch you can very quickly communicate many aspects of a website’s functions and features include user journeys, process flows and interface design. What’s more the spontaneity of a sketch is both appealing and can explain some concepts far better than words.
Functional specification
Perhaps the most comprehensive way of describing website functionality but also the most time consuming to produce and read. A functional specification will cover the functionality of the site on a page by page basis as well as explaining its structural architecture.
Often the functional spec will include details of the site’s intended audience and describe how they will interact with its features. In this case the specification may include personas of differing levels of detail.
Other documents that describe functionality might be inserted or referred to in the document. For example wireframes of key pages or flow diagrams could aid clarity.
Page definition document
The page definition document (PDD) describes the functionality of each individual page. It is often laid out in the form of a table
Wireframes
Wireframes instantly give the reader a sense of how a site is laid out and which elements are the most important. They can be augmented by adding notes which describe particular functionality and can include design elements such as logos or actual product images but I believe they should shy away from visual design as much as possible.
User stories
User stories present real site usage scenarios, reflecting how the site will function. For example, “as a customer I can place products in my basket and view it’s contents at any time”. They are easy to read and present technology in an easy to understand way, concentrating on what a site does, rather than how it works. They are time consuming to produce though.
Flow charts
Complex functional paths are perfectly represented by flow charts. They don’t have to refer to individual pages instead describing processes or steps of the website’s functionality. You will often find that a website may require several flow charts to represent its various functions.
Concept models
Concept models are diagrams that describe how different elements or features relate to each other. They indicate the underlying ideas or processes of a website and are represented as conceptual nodes linked together by arrows or lines that describe a relationship. For example you may have two hubs labelled “products” and “features” linked by an arrow labelled “benefits”, i.e. products are linked to features by benefits.
Site plans
A site plan is a visual representation of a website’s structure which shows how each page or group of pages is related to others. They tend to have a hierarchical tree structure or follow a hub and spoke model where a larger or more complex site is described.
Prototypes
At one time wireframes were the standard method for representing the visual, functional layout of a website but as more and more interactive functionality became commonplace prototypes (also known as grey shade prototypes or clickable wireframes) have become more popular. They can either be simply produced HTML-driven representations of pages or use complex animation tools like Flash to show how the site works.
Whatever system is chosen, their main advantage is that they emulate the interactivity of a website and the response it has to user input.
Summary
The table below summarises the various features and benefits of each technique.
| Technique | What’s good | What’s not so good |
|---|---|---|
| Sketch | Quick, easy and spontaneous. Ideal during meetings | Not suitable for formal documentation |
| Functional specification | Very detailed and comprehensive. Can explain functionality in detail | Time consuming to produce. May be to “dry” for some readers |
| Page definition document | Reasonably quick to produce and breaks the site down by pages | Requires the reader to visualise the page |
| Wireframes | Quick to produce. Visually represents the structure of a page | Stakeholder may mistake them for design layouts |
| User stories | Explain site functionality in an accessible, real-world style | Time consuming to write |
| Flowcharts | Visually represents complex processes | May be confused with a site plan |
| Concept models | Visually represents site concepts | May be a little to abstract for some readers. Could be mistaken for a flowchart |
| Site plans | A good visual representation of the hierarchical structure of a site | For particularly large or interconnected sites they may become very complex |
| Prototypes | Excellent way of showing functionality in action | Time consuming and expensive to produce |
