# Design Process

&#x20;The basic Design Thinking process is:&#x20;

1. Empathize
2. Design
3. Ideate
4. Prototype
5. Test&#x20;
6. Then rinse and repeat until your product adequately meets the user's needs.&#x20;

You can learn more about the Design Thinking process at [interaction-design](https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process). Don't be intimidated by Prototyping and Testing. The great thing about Voice Interactions is that the prototypes can be very low-fidelity with no programming necessary. All you need to do is find a few willing participants to act out the interaction of your skill. You can read more about prototype testing later in this guide. &#x20;

Once you have decided what problem you want to address with your skill it's best to start thinking about the user's jobs to be done. Jobs Stories are similar to User Stories, but we find them to be a little more streamlined. The basic problem is defined in three parts, The Situation, The Motivation and Goal, and the Intended Outcome. They can be written like this:

> When \_\_\_\_, I want to \_\_\_\_, so I can \_\_\_\_.

Throughout the Voice User Interface Design Guidelines we will be taking a look at example work from a Moon Phase Skill that is designed to give the user information about the Moon phase. Below is an example Job Story from the Moon Phase Skill.

> When I'm thinking about taking moon photography, I want to know what day the next full moon will be, so I can plan on taking photos of the moon that night.

The great part about Job Stories is that they do not dictate a solution. For example this job story could be resolved with a traditional mobile app. However, using a voice interaction is probably quicker than launching an app. Thinking about your user's needs in terms of Job Stories helps you determine whether or not a voice interaction is the best solution.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mycroft-ai.gitbook.io/docs/skill-development/voice-user-interface-design-guidelines/design-process.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
