Specifiying Fucntional Web Specification

by Nicolas Burki

Ineffective functional specification for Web projects such as Web sites, Intranets or
Portals contribute largely to delays, higher costs or in applications that do not match
the expectations. Independent if the Web site, Intranet or Portal is custom developed or
built on packaged software such as Web-, enterprise content management or portal
software, the functional specification sets the foundation for project delays and higher
costs. To limit delays and unexpected investments during the development process, the
following pitfalls should be avoided:

::Too vague or incomplete functional specification::

This is the most common mistake that companies do. Everything that is ambiguously

or not specified at all, developers do not implement or implement in a different way of

what site owners want. This relates primarily to Web features that are considered

as common user expectations. For example, HTML title tags, which are used to

bookmark Web pages. The Web steering committee may
specify that each page contains a page title, but does not specify that HTML Title tags
needs to be implemented as well. Web developers therefore may do not implement HTML
Title tags or implement them in a way, which differs from site owners’ visions. There
are other examples such as error handling on online forms or the definition of ALT texts
for images to comply with the disability act section 508. These examples look like
details but in practice, if developers need to modify hundreds or even thousands of
pages, it amounts to several man-days or even man-weeks. Especially, the corrections for
images as business owners need first to define the image names prior that Web developers
can implement the ATL texts. Ambiguous functional specification can result due to the
lack of internal or external missing usability skills. In this case, a one-day usability
best practice workshop transfers the necessary or at least basic usability skills to the
Web team. It is recommended, even for companies that have usability skills or rely on
the subcontractor’s skill set, that an external and neutral consultant reviews the
functional specification. Especially, as such reviews relate to marginal spending as
compared to the total Web investments (e.g. about $10 K - $15 K dollars for a review).

::Future site enhancement not identified or not communicated:::

It is crucial that the Web committee identifies at least the major future site enhancements and communicates
them to the development team. In the best case, the development team knows the roadmap
for the coming three years. Such an approach allows the development team to anticipate
implementation choices to host future site enhancements. It is more cost effective on
mid- or long-term to invest more in the beginning and to build a flexible solution. If
Web teams do not know or even ignore future enhancements, the risk for higher investment
increases (e.g. adding new functionality in the future results in partially or at worst
in totally rebuilding existing functionality). Looking at the financial delta for a
flexible solution versus a solution just satisfying the current requirements, the
flexible solution has proven to be more cost-effective in practice from a mid- and
long-term perspective.

::Planned functionality not aligned with internal resources:::

Many companies look at site functionality only from a site visitor perspective (e.g. facilitation of searching
information or performing transaction) and corporate benefits (e.g. financial benefits
of self-service features). However, there is a third dimension the impact of site
functionality on internal resources. Site functionality that can heavily impact internal
resources are for example:

- Web sites: providing news, online recruitment, online support, etc.

- Intranets / portals: providing content maintenance functionality for business managers

It is crucial for the success of site functionality that the Web committee analyzes the
impact and takes actions to ensure operations of the planned functionality. For example,
providing the content maintenance functionality to business owners and product mangers
with an associated workflow. This functionality is effective and can generate business
benefits such as reduced time to market. However, in practice, business owners and
product managers will need to write, validate, review, approve and retire content. This
results in additional workload. If the Web committee has not defined in the Web
governance (processes, policies, ownership and potentially enforcement), it may happen
that this functionality is not used and hence becomes useless.

::Wish lists versus actual needs and business requirements:::

The functional specification is not aligned with user’s needs or business requirements. This is more
common for internal applications such as Intranets or portals. In many cases, the
project committee neglects to perform a sound internal survey and defines functionality
by generalizing individual employees’ wishes without any sound proves. Capturing the
feedback of internal users across the organization allows determining the critical
functionality. To effectively perform a survey a representative set of employees need to
be questioned. Further these employees need to be categorized into profiles. The
profiles need to be characterized by for example, frequency of usage of the Intranet,
estimated duration by visit, usage of the Intranet to facilitate their daily tasks,
contribution to the business, etc. Based on this information the Web team can then
prioritize the functionality and choose the most effective and relevant functionality
for the next release. Less critical or less important functionality may be part of
future releases (roadmap) or dropped. If such a sound decision process is not performed,
it may happen that functionality is developed but only used by few users and the return
of investment is not achieved.

::Not enough visual supports or purely text based::: Textual description of Web
applications can be interpreted subjectively and hence leading to wrong expectations. To
avoid setting wrong expectations, which may are only discovered during development or at
worst at launch time, functional specification need to be complemented by visual
supports (e.g. screenshots or at best HTML prototypes for home pages or any major
navigation pages like sub-home pages for the major sections of the site such as for
human resources, business units, finance, etc.). This allows reducing subjective
interpretation and taking into account the users’ feedback prior development. Such an
approach helps setting the right expectations and to avoid any disappointments at the
end once the new application is online.

We have observed these common mistakes, independently if companies have developed their
Web applications internally or subcontracted them to an external service provider.

Nicolas Bürki is the founder of effinfo.com, a European based usability and Strategic
Web Marketing company providing you actionnable and pragmatic publications on online
marketing, usability, Web strategy, Web Goverance. Our consulting engagements are
delivered in English, French and German language.

Benefit from our freely availabe Web publications

Subscribe to our FREE monthly newsletter on Web design, usability and strategic Web
marketing.

Subscribe to our FREE Webinars providing you pragmatic advise on how to boost your Web
sites.

::About the Author::
Nicolas Bürki is the founder of Media Design Studio, Creating

Subscribe To Our RSS Feed
You can trackback from your own site.

One Response to “Common Mistakes:”

1

disability act…

I Googled for something completely different, but found your page…and have to say thanks. nice read….

Posted by disability act on March 8th, 2007

Leave a Reply

You must be logged in to post a comment.