System Story – the little sentence that builds big things
We know that a project kick-off workshop always means obtaining a lot of information. Furthermore, the product design journey can be long and bumpy! In our product design and development process here at Boldare, 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 in any successful development project! Read on to find out why it’s worth working on a 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. By the end, we have understood the project in detail and just need to create a single answer to four 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 answered in one sentence and… voila! We have our system story - a summary of the whole project in a single line. 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. However many people at the workshop, however many sentences… we only need one, a single perfect sentence, approved by the team and the client.
Verify your assumptions
I’ll give half of my kingdom to the person who knows everything about a 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 to be the core problem really the problem we want to solve?
To take an example, before the workshop with our client from Vancouver, we were familiar with the whole product vision. We were almost certain that we were to build a catalogue of sconces designed 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 chooses a certain sconce from the product list (designed by us), then includes 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 they became our story users! The system story gave us the certainty that we could be sure we had found the perfect user. The rest of the project was about answering to that user’s needs.
Good navigation throughout the design process
Another key point is to remember the user’s needs and business values. The system story stays with us during the whole release. Only such verification provides a strong and effective product.
Our collaboration with a client from the Saudi Arabia is an example. Our main goal was to create the best search offers for Saudi travelers. The product had to respond users’ 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 critical. There were many features on the key view, but we knew our user and his needs. We focused on a quick, useful search with dedicated and matched results. Each increment was verified with the system story.
Finally, we built a useful, modern and intuitive booking engine, responsive to today’s needs. That was a huge challenge. But a good system story guided us quickly to the right solution.
A small thing but a weight of gold
From the very start of a project, throughout its implementation, to product testing, the advantages of a system story are clear. The Product Owner verifies the project assumptions and clarifies the final vision with the stakeholders and the team. The developer’s team is sure what, for who and why the product is needed. This allows them to verify further features.
Finally, it gives comfort and certainty for all, that everyone is on the same point and has the same knowledge. It helps build 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 the product users and verifies the business need. It helps to build the right product for a particular user which responds to real needs. Furthermore, it helps to avoid basic, major mistakes. That saves money and time in the long run. From the other hand, it also provides the comfort and certainty that everyone is on the same point, has the same knowledge and is following the same path to reach the business goal. And it really binds the team together.
However, it’s only the tip of the iceberg. There are many other traps on the design process road. But more about those in subsequent posts…