When a vendor is designing a website for a client - an organisation with Business Analysts and Project Managers assigned to the project - we need to provide concepts/wireframes and with annotations, reference Business Requirements (e.g. a sign-in link must be visible on all pages OR "Advertisement A" must be above-the-fold for screen resolutions 1280x1024 (60% of visitors)).

I want to make sure that when the question is asked, "Why is that news widget inserted in that position of the page?" that there is no scrambling around for rationale. I want to quickly identify:

  • What Business Requirement this element refers to
  • What interview/study supports this element being in this location
  • What assumptions must the client be aware about the element being in this location
  • Where are the variations that each element may inherit

What is the standard of validating Business Requirements? Is it typically through a spreadsheet, a meeting?

  • Those examples don't sound like business requirements. They sound more like product requirements (or, more likely, client wants). I'd also be wary of micro-documenting every detail cross-referencing client requests. I'd present it a bit more generally than that.
    – DA01
    Commented May 16, 2012 at 0:41
  • Like DAO1, I'd be wary of using documentation to communicate these needs. Requirements specifications have to be defined in a lot of detail, and you won't want to invest all that time upfront only for the client to reject the decision. Documenting reasons for a particular design takes a long time, and is overkill when most decisions (statistically) won't be questioned. Commented May 16, 2012 at 0:44

1 Answer 1


I've seen this handled as by establishing traceability through the following documents:

  1. A stakeholder needs document that describes what needs/problems exist that are within the (long-term) scope of the product (each need gets a unique ID)
  2. A specification document that describes the solution in terms of the problems. This is basically a first-pass collection of user stories; features framed in terms of their audience and the need they address. Each spec item refers to one or more needs in the first document.
  3. Wireframes and high-fidelity proofs can then be produced and refer to specific needs and/or stories by ID in annotations
  4. Usability test reports are produced to document observations (effectively representing new needs), and then bugs and/or features are added to the specification referencing those usability test observations

Still, all that overhead drastically increases the cost of doing business so don't commit to doing all that if you can help it; instead, the easiest route is to have periodic UX reviews in person with a group of stakeholders where the UX designer can present the changes/additions in terms of the need and/or best practice. That will inspire confidence that decisions are being made based on real design and investigation and hopefully allow you to iterate much faster (which is a huge victory when it comes to UX since you get more regular builds/prototypes to usability test).

  • 1
    Hi Kit, thanks for your very detailed and informative response. In my example, I am the internal designer of a large organisation who is outsourcing a website job. The requirements were set before any design work had commenced and now, as we are going through design iterations, we are ticking off the requirements. I am finding it an overly complicated and at times, unnecessary task. Thanks again for your response.
    – rlsaj
    Commented May 18, 2012 at 23:41
  • No worries. Dealing with vendors is a good example of the sort of situation where documentation is necessary. One topic I didn't mention in my answer but could have is functional testing—a test protocol can be written referencing the expected behaviour from the spec by ID to ensure the delivery is a good fit for the requirements that were defined.
    – Kit Grose
    Commented May 20, 2012 at 23:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.