Design Thinking : Test

Now we have moved onto the step in the design thinking process.

In this one, we will finally test what we made and get some feedback to improve on it in an endless cycle.

You can simply take your prototype to the user and ask them to give their feedback. You can also use the user journey template mentioned before to record their responce for further development.

When you are testing, make sure to prioritze your tasks and build a to-do list of what elements you want to include and test in what order.

MoSCoW Method

Must have: essential elements for the product
Should have: what should be done if possible
Could have: items that could be done if they have no impact on other tasks(comfort + feautres)
Won't have: only to be done if team has time

Some Points

• the point of the test is to collect feedback from it's users
• asks the user and market many questions and presents them with many sernarios to gain a sense of what they will do
• must be prepared and planned in advance with an objective as to what exactly you want to test/what part is to be tested
• do not fall in love with your product as you will not improve it then
• take notes/document the testing as the user is using the product
• try to spot things that can be done better

What works | What can    |
well       | be improved |
-----------|-------------|
Questions  | suggestions/|
(that user | ideas       |
askes)     |             |
-----------|-------------|

• ask the user to describe what they see, think and feel

A/B Testing
The way this works is to test two options at the same time. I will be using the example of different button colours to add something to your shopping cart.

This can also apply to other UI elements such as various fonts, layouts, colours, animations and other features.

• Can be done in cojunction of the main prototype testing or done seperatly

Now let's say you have two UI, one with a yellow button and one with an orange one. You would then assign each one to group A or B that each has an equal amount of users that are as diverse as possible within the TA.

You will then see the results, suppose users like the orange button more than the yellow one. You can now test that against a green button and so on and so forth.

Sailboat Retropective
It is a useful way for teams to evaluate themselves and consists of a few main parts.

• The Island (Goal): The destination or the objective the team aimed to reach during the sprint.
• The Wind (Propelling Forces): What pushed the boat forward—factors that accelerated progress, such as good collaboration or new tools.
• The Anchor (Obstacles): What held the boat back—challenges, bottlenecks, or, for example, poor communication that slowed down progress.
• The Rocks (Risks/Icebergs): Potential future risks, dangers, or obstacles that could cause trouble in upcoming sprints.
• The Sun (Optional): Represents what made the team feel happy or positive during the project

How to run this retropective:

• Set the Scene: Draw a sailboat, an island, wind, anchors, and rocks on a whiteboard or virtual tool
• Brainstorm: Ask team members to write down thoughts on sticky notes and place them in the corresponding categories (e.g."slow internet" on the anchor"great pair programming" in the wind)
• Group and Discuss: Group similar notes together to identify patterns. Discuss the items, particularly focusing on what is slowing the boat down
• Create Action Items: Vote on the most critical issues and define concrete action items to address them in the next sprint, assigning ownership to specific team members

There are quite a few benefits to doing this, including:

• Visual and Engaging: It is more creative than a standard text-based retrospective, increasing engagement
• Clear Insights: Helps identify both immediate blockers (anchors) and future risks (rocks)
• Encourages Openness: The relaxed, metaphorical format helps team members feel safer discussing failures and successes.

Have fun!