This version of the course is several years out of date and parts of it will not work - it is here just for the benefit of my 2022 dissertation students who want some grounding in Leaflet and associated technologies.

Jonny's Guide to Writing a Design Rationale

What is a Design Rationale?

When designers (web designers, furniture designers, graphic designers, architects etc.) present their work, it is typically accompanied by a rationale that explains how their solution answers meets the associated design goals. There are a lot of different types of design rationale, and most of them are far too complicated for what we are looking for here. This is based upon they type of document that you would present to a client alongside a website that you had made for them.

A well-written design rationale is invaluable in explaining how your design solution satisfies the defined goals. This is your opportunity to explain the choices that you have made to the client, even those that they might never realise had been made. In doing this, the design rationale is an opportunity to ‘show your working’ - it is a chance to explain your thinking, illustrate the benefits of your solution, and ultimately to help sell your idea (or, in the case of this course, get a better mark!).

A written design rationale rationales is required as part of your assessment, but in the workplace they are also useful tools for organizing your thoughts, as well as a valuable resource for you if you later decide to put together case histories of projects a portfolio. When writing your rationale it’s always helpful to have access to some visual documentation of your design process such as rough sketches, early screenshots, and so on.

Design Goals

Remember that your Design Goals are very important, and should be determined before you start developing your website. They are simply a list of things that your site should achieve, and are normally based around things such as whom your website site is aimed at and what key information your website is intended to communicate.

Your rationale will then simply assess your product against those predefined design goals, and justify how your design and functionality supports them. Details to include might include:

  • the reasons behind and justification for a design decision
  • the other alternatives considered
  • an evaluation of any comprimises that had to be made in the design
  • the though process that led to the decision.

Writing your Rationale

Here are some things to keep in mind when writing your design rationale:

  • At the top of the page, at the very minimum state the name of the client and the name of the project. It’s sometimes also helpful to provide a short summary of the project.
  • Clearly and concisely state your Design Goals (normally as a list of bullet points), these are the criteria that your design is aiming to satisfy.
  • Be sure to fully explain the overall concept of your design, e.g.:
    • what is it
    • who is it for (audience)
    • in what context will it be
  • Once you have explained your goals, you can then go into details, giving reasons for specific design decisions that you have made.
  • Remember – it’s a rationale (requiring the reasons or logic behind your decisions), not a description. Don’t just say what you’ve done – explain why you’ve done it, referring back to the design goals, the audience and the purpose of the website.
  • Don’t admit to arbitrary decision-making or say that you used a particular colour/font/technique just because you like it. Every choice you’ve made should be relevant to the brief. What effect does the colour/font/technique have? What does it communicate? If it’s not relevant, don’t mention it.
  • Keep your reasoning honest. It’s easy to spot convoluted after-the-fact rationalisations, but these are not very helpful.
  • Don’t focus upon approaches that you rejected unless they provide an explanation for the final work.
  • Don’t mention what you would have done if you’d had two more weeks to work on it. It’s time to present your work, and you should do so with as much confidence as possible.
  • Try to avoid passing judgment on your own work, either positive or negative. It’s necessary to say why and how your solution satisfies the brief, but statements such as “this solution is amazing” or “this isn’t my best work” are not helpful.
  • Don’t forget the “e” on the end of the word “rationale”!

Some of the above is adapted from this article from the Graphic Designers of Canada (GDC).

This course has not yet begun.
Course material will appear here week by week as the course progresses.