The Big Why: focusing on the reason why and the impact of the expected IOT app product.
Simone Crimella
Product Service System Designer
Remote workshops using MURAL
Activities for La Marzocco App Professional
The project
This document consists of a summary of the activities carried out during phase zero of the App Professional La Marzocco project. Phase zero began with Design Thinking exercises aimed at understanding the vision, motivations, goals and kpi of the La Marzocco App Professional in order to align the team towards a shared product idea. The identification of the target through the Personas Mapping & Task Analysis exercises made it possible to understand their main tasks as well as the context in which these people find themselves working everyday and provided the basis for the drafting of a first set of functions to be included in the MVP.
Thanks to those two weeks of Design Thinking it was possible to kick-off the project in an organized way and prioritize the most relevant activities to be carried out by the design and the development team.
Workshop Schedule
Activities Performed:
Day 1 - 29.04.2020
Vision
Elevator Pitch
Technical Requisites
Goals
Day 2 - 06.05.2020
Target Personas
Tasks As-Is Analysis
App Features & Functionalities
Day 3 - 11.05.2020
MSCW
Day 4 - 13.05.2020
Funzionalità Must, Should, Could e Would
Day 5 - 18.05.2020
Roles and functionalities
Day 6 - 20.05.2020
List of all alerts typology available
Technology ecosystem design
Services architectural models
App Architecture
Measurement capabilities
Workshop activities
16
People
8
Exercises
6
Appointments
1
Virtual Platform
4
Departments
Vision
The Big Why
This exercise aimed at identifying the purpose of the project and the expected result through the answers provided.
PROCEDURE:
Each participant wrote their "why" on a single post-it.
At the end of the dedicated time (5 minutes) we took 5 minutes to discuss it.
The answers were read and discussed publicly. After that each participant expressed their preference by applying 3 dots (max 2 for post-it) in box A and 3 dots (max 2 for post-it) in box B.
The answers with most votes got selected as the Reason Why and the Expected Impact of the newly to be designed product.
TIMING:
40 Minutes
Results
Elevator Pitch
Elevator Pitch: an effective way to describe a product/service idea.
Elevator Pitch
An elevator pitch is a description of an idea, a product or a company that explains concepts in a way that any listener can understand immediately. The goal is to convey the general concept in a persuasive and effective way.
PROCEDURE:
For (Target User)
who has (User need)
App Professional (Product Name)
Is a (typology)
That (one key benefit)
Unlike (other known things)
The product (differentiating feature)
TIME:
40 Minutes
Results
Goals
Goals canvas: a good way to focalize the attention and push people to choose wisely their goals.
Goals
Project goals served to align the stakeholders so that the imposed objectives could be devised following the S.M.A.R.T. logic:
Specific: Adequate or challenging but at the same time achievable
Measurable: Measurable through suitable indicators to measure the result you want to achieve.
Achievable: Adequate or challenging but at the same time achievable. Even in the case of a rationalization objective, it must aim at an improvement or rationalization of work.
Realistic: Realistic with respect to the resources available.
Timely: Limited in time
PROCEDURE:
Each participant wrote on a post it what the main goal of the project is, respecting the S.M.A.R.T. criteria.
TIMING:
40 Minutes
Results
Personas
Main personas canvas. The information were extracted and translated after showing the ten personas below.
First Persona: Baristas
Based on the knowledge our client had of their customers, we set up two personas for whom the app must've been designer for. We referred to them throughout the entire product development process.
PROCEDURE:
I personally summarized the main character.
TIMING:
1 hour
Proto personas brought to the table
Main tasks matrix
Main Tasks matrix
The Main Tasks matrix allows to represent the flow of actions that each role needs to perform along the process, highlighting the actions that the user can see (above the line of visibility) and the ones that happen in the back-office (below the line of visibility). Roles can be performed by human beings or other types of entities (organizations, departments, artificial intelligences, machines, etc.).
PROCEDURE:
Each participant contributed with their personal knowledge of the daily activities of a Barista.
TIMING:
40 Minutes
Functionalities
Main functionalities canvas
Features and functionalities
To facilitate the identification of key features to be included we completed a matrix with all the main stages of the service architecture envisioned.
We presented our categorization and explained why some features had to be included in the secondary categories.
PROCEDURE:
After a brief recap of the main personas using the machines, as well as their main activities emerged whilst analyzing their daily tasks, we were able to come up with 16 main points to be analyzed.
TIMING:
40 Minutes
M.S.C.W.
Must Should Could Would canvas: a very efficient way to create and organize an actionable backlog.
Must Should Could Would
To facilitate the work we completed the MSCW trying to highlight our point of view on the key functionality.
During the first part of the meeting we presented our categorization and explained why some features had to be included in the secondary categories.
Subsequently, a period of individual reflection followed, aimed at understanding whether the functions of the Must column were rightly validated by everyone.
Our categorization was structured as follows:
Must: Essential set of functionalities to be included in the first app release. These functionalities were not to be missed in order to open and allow users to use the app.
Should: Important functionalities that should have been included in the app first release but that weren't at the same time essential for it to function.
Could: Important of functionalities which aren't fundamental during the first release. Those functionalities were set to be deployed after all the Should and Must functionalities were correctly delivered.
Would: Desirable functionalities that should have been taken in consideration once finished the Could, Should and Must ones.
PROCEDURE:
Each stakeholder took part to the discussion and gave their vote on the functionalities to be included in the MVP.
TIMING:
2.5 hours
Alerts
Alerts types and requisites
Alerts typology and tone of voice
A list of Alerts, including all the necessary primary maintenance messages were collected and analyzed.
After this, a Tone of Voice and Requisites were aligned with the chosen design language and style, in order to create a continuum with the ongoing design process.
PROCEDURE:
Each attendee verified the relevance of each alert according to the initial strategy identified in previous workshops.
TIMING:
1 hour
Project Main Results
Main design and development tasks emerged.
Prioritized functionalities
At the end of the six days workshops, a crystal clear workshop report was submitted to our client. Among the main submission documents there was the set of functionalities emerged during the design thinking exercises.
Tech players ecosystem
Technology Ecosystem
A clear map of technological service providers and how these companies provided the service within the App Professional.
App Architecture
Architecture and Services modeling
A visual representation of how data flows between the different platforms identified.
App Professional scheme
App Scheme
The architecture of the app serves to visualize the positioning of key features within a logical scheme focused on the user's needs. Pages with a blue frame represent core functionality essential to the first release of the app.
The dashed sections represent a topic for discussion and need further analysis
User roles and functionalities matrix.
User Roles
Following technical meetings useful for understanding design limits, it was essential to envisage two different roles to ensure proper use of the app and machines by end users.
The differences were then defined on the basis of the Task Analysis and technological constraints.
The following page illustrates the differences between the Admin role and the guest role.