I agree with Rich about not wanting to change the focus to project management or reporting. So while I don't document these abandoned ideas, I do record Jing demos for each iteration.

The intent of these demos is to give engineering a narrated tour of wireframes. In doing so, I've found a useful by-product of this is that I can go back to my earlier drafts and listen to how I was explaining the design at the time. I find this to be more useful than referring back to my own notes, as my notes aren't trying to be persuasive and explain my motivations for designing something a certain way.

Hi Nathalie

I don't usually have the time to fully document our successful design decisions so I'm not sure that I'd ever get round to formally record designs or features that were thrown out as part of the iterative process, or the rational for what what we didn't do.

But I think that your question is really interesting and my approach would depend on reasons why you need to provide this documentation:

• to show the rigour of your process (like including your calculations on a maths exam so that examiners can follow your thoughts and give you credit, even though they don't agree with your conclusions)
• to cover your back and demonstrate that "of course you tried feature x but it didn't work because.."
• to document anti-patterns for stuff that you don't want other teams to implement in future releases - things that seemed like a no-brainer but turned out to be a really bad idea

It also depends on when such rational or justification will be used. Long complex integration project always require more formal documentation and justification.

My approach would be to drag stakeholders deeper into the design and ideation phases so that they can see it happening. But it's not always possible to use this sort of participative design, and in any case you probably just need something that a stakeholder can show their boss so prove that everything is going to plan.

Regular status reports using spreadsheets to communicative RAG status against features designed, decisions made, requirements met and other project tracking metrics may help. You could also record screenshots of prototypes at various stages in the design process to show improvements over time. These could be annotated later if it was necessary to expalin why things were removed.

But all this adds administrative overhead to the project and shifts focus of the UX lead from designing to project management and reporting....

Cheers
R

Hi Nathalie

When writing recommendations to my clients i have adopted the following format:

• Recommendation: Description of the recommendation
• Rationale: Why this is recommended
• Best Practice Guidelines: A list of best practice sources with key guidelines highlighted.

Eg

Set user expectations at the start of the form

Recommendation: Create a start page that sets the customer expectations at the start of the process. The goal is to:

• Outline what information the customer will need to hand to complete the process and approximately how long the process will take.
• Link to terms and conditions.

Rationale: When a form/process require a significant time investment or when people might get frustrated when getting halfway through a form only to discover some obscure piece of information is preventing them from finishing, you should consider using start pages to help illuminate a clear path to completion.

Best Practice

• Form Design/Usability - For forms requiring substantial time or information requiring look-up, use a start page to set people’s expectations.
• Form Design/Usability - Ensure that the titles of your forms match people's expectations and succinctly explain what each form is for.
• Form Design/Usability - Make sure that you illuminate a clear path to completion through a form by using clear scan lines and effective visual pacing that comfortably takes people from start to finish.
• Form Design/Usability - For forms with a known sequence of multiple Web pages, include progress indicators that communicate scope, status, and position.

I then cite the resources in an addendum to the document.

EDIT: A quick note usually i include screen grabs of where this is done well.

EDIT - After Question Clarification.

I don't explicitly capture the lost requirements in a single client deliverable. Honestly this is because I believe the document should be live and reflect the project as it now. (I don't believe it's useful to the client or their development team to increase the document size they need to mine through to work out what to do next.)

That said. I version all my documents and create contact reports for all meetings where the document is discussed. If the action is to remove a requirement I briefly note the reason.

So when a request is re-discussed i'll know whether it was included in a previous version and can go back through my contact reports to understand the rationale.

HTH

Matt