Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
    
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 May 16 '12 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. –  Jimmy Breck-McKye May 16 '12 at 0:44
add comment

1 Answer 1

up vote 1 down vote accepted

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).

share|improve this answer
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 May 18 '12 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 May 20 '12 at 23:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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