Documenting the Design Rationale Behind a User Experience Design
Many of the user experience designers I have worked with in web projects have been very skilled and experienced. Even so, I have rarely encountered a designer who has explicitly documented the rationale behind the design - why a certain design decision was made, what alternatives that were considered and why they where discarded during the design process.
Documenting the design rationale can be as simple as providing some pros and cons together with each design sketch and then recording which design sketch was chosen and for what reasons. If any changes are made in-between two sketches, those should of course also be described and motivated.
One of the main benefits of documenting the design rationale is that it is easier to anchor the design with stakeholders. Besides that the designer probably will have to think through the design suggestions more (which will probably lead to a better design in the end), it also forces stakeholders to motivate both their decisions and any critique of the design suggestions. Simply put, it will be easier to discard all those personal opinions (“I want to have the button there”) that are a nuisance in most design processes. You simply point to the common practices, best practices, usability heuristics, guidelines etc that you have motivated the design suggestion with. It will move you faster to a final design and can radically shorten the design process.
I have twice in my career experienced how someone in the upper management has suddenly intervened in the design process and decided to change from one icon to another. I don’t know if it is common that managers possess special skills in icon design and usability or if these situations really can be avoided by documenting the design rationale, but at least decisions like these will be documented with why and by whom the decision was made. As motivation behind the design decision it will probably have to say “Because manager X wanted it”.
Documenting the design rationale can be as simple as providing some pros and cons together with each design sketch and then recording which design sketch was chosen and for what reasons. If any changes are made in-between two sketches, those should of course also be described and motivated.
One of the main benefits of documenting the design rationale is that it is easier to anchor the design with stakeholders. Besides that the designer probably will have to think through the design suggestions more (which will probably lead to a better design in the end), it also forces stakeholders to motivate both their decisions and any critique of the design suggestions. Simply put, it will be easier to discard all those personal opinions (“I want to have the button there”) that are a nuisance in most design processes. You simply point to the common practices, best practices, usability heuristics, guidelines etc that you have motivated the design suggestion with. It will move you faster to a final design and can radically shorten the design process.
I have twice in my career experienced how someone in the upper management has suddenly intervened in the design process and decided to change from one icon to another. I don’t know if it is common that managers possess special skills in icon design and usability or if these situations really can be avoided by documenting the design rationale, but at least decisions like these will be documented with why and by whom the decision was made. As motivation behind the design decision it will probably have to say “Because manager X wanted it”.