Design specifications

Design Specifications are a product of design that are created by keeping detailed notes about the analysis, scope, and design decisions for an educational product. Documentation of design specifications can be completed in any way that records the decisions of the designers, the look and feel of a design, and descriptions of the activities, technologies, and media that are used in an educational product.

Definition

The design specifications of an educational product is a document produced by a designer or design team that consciously documents and captures their ideas, work, decisions, and descriptions of the activities, technologies, interfaces, look and feel, and informational media of the product.

Additional Information

Design specifications are written documents that outline and describe the project scope and the design features of an educational product.

In the case of products that have not yet been developed, proposals for an educational product design are simply design specification documents that have yet to move to the later design and development phases of the ADDIE Model.

What design specifications are included to describe a product?

Design specifications are typically written for each design feature within an educational product. This includes writing detailed descriptions and specifications for each of the items that define and describe the product.

A complete document of design specifications for an educational product or experience will generally follow a structure called W6H that identifies who, what, when and for how long, where, why, how, and with what effect of the design:

The product scope, which includes:
- The goals of the design team (answering "why does it matter" if the product is developed)
- Who will be learning (i.e., the audience considerations and its constraints)
- What will be learned (i.e., the learning outcomes and any associated constraints)
- When and for how long the activity will take place (i.e., the duration and timing of the product and any associated constraints)
- Where learning will take place (i.e., the location setting of the product and any associated constraints)
- Why the product is expected to work (i.e., how learning theory predicts why the product will work)
How the product will be used and how it is expected to facilitate learning, which includes documenting every unique design feature including:
- Activities and interactions that both participants and teachers need to do, documented with detailed descriptions, prototypes, and conceptual drawings
- Interfaces and visual elements, documented with descriptions, mockups, and conceptual drawings
- Educational technologies, software, apps, and technical functionality to be used within the product, documented by descriptions, prototypes, and conceptual drawings
- Informational media that will be used, such as text, audio, video, animations, websites, or other multimedia resources.
Through a well-planned evaluation and assessment, identifying with what effect the product helped people learn and whether the product was used as expected

A full set of design specifications will have each of these elements from the W6H approach. Each distinguishable or unique design feature should be defined and given design specifications in a well-planned design.

Common components of design specifications

Individual design specification sections that describe the scope or design features of a product should be as detailed as you can make them without becoming repetitive or unnecessary. Writing design specifications is more of an art than a science and will take some practice! Some design specifications only need to be short descriptions that define the scope element or design feature and rationalize why something is needed. Some specifications for more advanced design features can be multi-page documents that provide graphics, images, and mock-ups to help describe the concepts and ideas that define the feature.

Regardless, design specifications commonly include the following elements:

Text or other multimedia to provide a detailed description of each scope element or design feature
Descriptions of processes and actions, including the use of text to describe sequences and potential activities, as well as graphics like flowcharts, concept maps, or other diagrams to show how processes and activities should progress.
Images, graphics, illustrations, or conceptual drawings that convey visual information, such as how a design feature could or should look. This includes sketches, mockups, wireframes, concept art, and prototypes to convey the ideas in more than just words
Examples of similar products or features that share traits with the product being developed

Remember, every design feature should have a specification written to some degree, even if the specification is just a sentence or two long of text. This is especially true if the designer wishes to share the idea with other people or evaluate its effectiveness. Well-documented design specifications are the tell-tale sign of good design!

Why we document our designs

The process of documentation of educational designs through design specifications serves three purposes:

To provide detailed descriptions of each design feature that is used in an educational product, especially if multiple people or teams are working on a product. The specifications can be passed on to other people and be shared, which describe how the product should be actually build during the development phase.
To archive and help design teams think about the challenges, issues that arose, tasks, decisions, rationales, and specifications of the whole design process, including specifying each of the design features of a product. Such archiving is useful when preparing the product for distribution and needing to write or share about the product's design, features, and rationale. Documentation captures the "in the moment" thoughts and actions of the design team when
To have a source of information to reflect on and review when (a) iteratively improving the product by having recorded memory of actions taken and decisions when they were made, (b) needing source information for writing descriptions and reports about the product for sharing and distribution, and (c) conducting research on how to improve the design process itself. Some grant funders and purchasers require robust descriptions of products, as well as a complete and logically tied rationale for how and why design features were chosen or were built a specific way to meet the learning goals of the product.

Documentation is critical for reflection on the design process and how products might be improved. Additionally, teams may be expected to provide great detail on their products and show logical, well-reasoned decisions for how and why a product is designed the way it is.

Documentation also helps teams not only capture their thoughts and experiences, but is a process that assists them to actively think about how and why decisions are being made in the moment. Instead of waiting until a report is due months or years later and either forgetting entirely the process details or making things up, documentation gives teams a moment to capture how and why they made decisions in the moment.

Furthermore, a design without documentation makes it very difficult for an outside party to learn about and understand how a product works. When conducting evaluations of a learning product, a lack of design documentation also makes it very difficult to link the decisions as to how the product was designed and how and why it worked. The decisions and work must be defined, and documentation is the best evidence of that.

Indeed, documentation takes extra work to complete, but is a necessary component of robust design. Thus, designers should develop a habit of documenting their design work and decisions, much like a chemist or laboratory scientist keeps intricate records and notes of their experiments and lab work as the work is being done. Nothing is better at capturing the thought processes of a person in the moment than documenting and reflecting on the process in the moment.

Common items to document during design

There are many things for teams to capture in their documentation of designs:

Write down every detail of the project's design features when they are decided:
- Simply write descriptions of each main part of your design, what purpose it serves, how people are expected to use it, and what it could or should look like when it is developed
Provide illustrations, concept art, and visual descriptions when appropriate and possible
Simply writing down everything done (every task and sub-task), and why each was done
Design rationale for decisions made, reasons why things were done or how they are expected to work
Findings from the initial analysis/planning phases
Issues that arose while the design team was getting work done and how issues were resolved
Goals that were set for completing tasks, and how those goals were met
Discussion of the process of task completion, from start to finish
Ideas and brainstorms
Challenges that arise during development:
- Translating the design specifications to development and actual deliverables
- Issues that arise with developers or artists not interpreting the designs in the way intended
- Issues with technologies or designs not being able to be implemented as intended
Revisions made to design specifications and scope of work based on newly identified issues during development or implementation
How long it took to finish specific tasks (for future planning and time management purposes)

Common methods for documentation

Teams can also document their designs in many ways. The basic premise behind documentation is for designers to record and archive their process of work, and to have a moment to reflect on what, how, and why they are doing what they are doing. Designers who document well find that the reflection process is very valuable in helping them think through the reasons why they do things. This becomes particularly valuable later on in the design process when needing to describe the rationale for designs to people who are making decisions about adopting, downloading, or buying an educational product.

Documentation through project journals or notes. Much like a lab scientist will keep a lab notebook or lab journal. Doesn't have to be written, but written documents might be easier to share and analyze later. Project journals can be written on physical paper, on an electronic word document, or can also be an online web form with multiple fields or questions that can be saved into a spreadsheet. Many people also document by recording design sessions and team meetings, or by doing voice dictation where designers speak about their decisions instead of writing (a vocal log).
Documentation through generating specific documents on design features. Each of the design features may have a series of notes and decisions as they were developed. These should be created and preserved for review later on.
Documentation through daily reflective journaling and notetaking. Daily or semi-regularly journaling is a good habit and skill for a designer to develop. Journals can be prompted, in that the journal asks the writer similar questions every day, or the journaler can write openly (or record themselves speaking) about the things that they encountered each day and how they worked to complete each task. Tasks of course do not need to be completed each day, but a daily journal can record some of the progress made on each task and what factors influenced the decisions of the designer.
Documentation through project documents and deliverables. The actual documents and elements of the product, including all of the documents and deliverables, all serve as evidence of decisions and design choices that were made. Although the end results do not explain how and why, the product's end results are another part of documentation of the product's work.

Sample daily journaling prompts

Here are some sample journaling prompts that can be used for a designer who wants to record and reflect on their work on a semi-regular basis. Journaling does not have to be a daily activity, but daily journaling is useful toward capturing information at the highest resolution. Returning to journals can be an excellent source of idea generation and jogging memory on what issues were encountered and why decisions were made.

What are the projects and tasks you worked on today? (and date of entry)
What were your goals for working today?
What did you get done today?
How did your plan come together today?
What documents or items did you create today?
What did you continue working on today that you had been working on previously?
Did you revise anything today that you worked on previously?
General notes and thoughts about your work today (including concepts or ideas you were thinking about, design commitments you were thinking about)
What are some of the tangents and distractions that you thought about or set you off course
What outside information did you seek today to help you with your work, or did you get any help from an outside party
Did you have any social interactions today about your work, and with whom and why?

Tips and Tricks

Consider how you will document your work and keep a record of your thoughts, decisions, and reasons for your designs. You can start by just keeping a daily log of the tasks that you worked on, the things you completed, and how and why you made decisions the way you did.
More advanced documentation can be done by keeping a daily journal or log on your design work (see sample prompts above).
You should also keep documentation on the design specifications of each design feature. These can be in separate documents or media for each feature, or they can be in a single ongoing or "running" document that you use to capture information on how a design should look. Design specifications are a specific type of documentation that is essential for fleshing out a design, as well as handing off the design to any developers, artists, and other instructional designers who will be working with you. In short, the specifications for features are the blueprints for how to actually build the design and what actions people are specifically expected to take.

Design specifications

From The Learning Engineer's Knowledgebase

Contents