We know that a project kick-off always means obtaining a lot of information.
Furthermore, the product design journey could be long and bumpy!
In our Chilid process, there are many tools which help us navigate along the right path and verify our assumptions. We don’t want to keep them all under our hat!
Today, we reveal the first step which allows you to meet the target!
Read about why it’s worth working on the system story.
Don’t drown in the information jungle.
At the beginning, we have the entry brief, however, we can’t take it for granted.
That’s why the meeting between the client and the rest of the team is crucial. During this workshop, we define, little by little, a common vision and business goals. At the end, we get the message of the entire presumption and the last part is to find the answer to 4 little questions:
- What exactly are we building?
- How are we going to achieve our goal?
- Who exactly is it addressed to?
- And… a tricky one: what for?
This should all be connected in one sentence and… voila! We have a smart summary in one line! It is this which is exactly the system story and it’s the final conclusion. Don’t be under any illusion that it’s easy to write. In fact, you will dwell on it a lot before you create it believe me, how many people at the workshop, how many sentences… But we only need to build one, a perfect sentence, approved by the team and the client.
Verify your assumptions.
I’ll give half my kingdom to the person who knows everything about the yet-to-be-developed Product.
Of course, we ask a ton of questions and gather a huge amount of insight. This allows us to find a technical solution, come up with the general strategy, plan a team etc. This mass of information gives us a great overview but can we be 100% sure we know everything? Is what we assume the core problem we want to solve?
Before the workshop with our client from Vancouver, we were familiar with the whole product vision. We were almost sure that we were to build a catalogue with sconces dedicated for hotel interiors. During the system story, we verified all our previous assumptions. Our goal was to build an appealing, modern catalogue of customizable sconces. But… not for the hotel owners, for interior designers. We had to build a tool which would help them effectively sell the unique product to the contractors. The proper user path was: designer chose a certain sconce from the product list (designed by us), then include it in their interior project which will be shown to the final client.
We quickly realized that the designer is like a bridge between the owner of the business and our website. And he became our story user! The system story gave us the certainty that we could be sure we found the perfect user. The rest of the project was the answer to his needs.
Good navigation throughout the design process.
Another key point is to still remember the user’s needs and business value. The system story stays with us during the whole release. Only such verification provides a strong and effective product.
To support my point, I describe our collaboration with the client from the Saudi Arabia. Our main goal was to create the best search offers for Saudi traveling. The product had to respond their needs and find the most appropriate deal at a good price. The system story was helpful from the beginning. But when we were designing the wireframes it was pivotal. There were many features on the key view, but we had known our user and his needs. We focused on the quick, useful search with the dedicated and matched results. Each increment we verified with the system story.
Finally, we’ve built the useful, modern and intuitive booking engine as the response for nowadays needs. That was a huge challenge. But the good system story guided us quickly to the right solutions.
A small thing but a weight of gold.
From the project starts, through the implementation, till the testing. The advantages are for everyone. The Product Owner verifies the entire assumption and clarifies the final vision with the stakeholders and the team. The developer’s team is sure what, for who and why the product needs to be done. This allows verifying the further features.
Finally, it gives the comfort and certainty for all, that everyone is on the same point and has the same knowledge. It builds a fruitful relationship between the PO and the team too. So… it’s useful for everyone.
To sum up, the system story (also known as“the product story” or “the product statement”) describes product users and verify the business needs. It helps to build the right product for a particular user which response on real needs. Furthermore, such assumption helps to avoid the basic, major mistakes. That saves money and time in the future. From the other hand, it gives the comfort and certainty for all, that everyone is on the same point, has the same knowledge and follows the same path to reach the business goal. And it really binds the Team :).
However, it’s only the top of the iceberg. There are many other traps on the design process road. But about them in subsequent posts…