Functional analysis pushed me out of my comfort zone, and forced me to look at my ideas from a completely new angle. It forced me to dig deeper in the concepts I was suggesting, and taught me to understand the multiple complexities stemming from a functionality that on the surface seemed so simple.
I am not saying that technical constraints should constrain the creativity you want to put into a digital product, far from it. Nevertheless, understanding how things are made, and taking control on how your product will be built is key for you to :
- Be the guardian of the user experience : By giving detailed tought on how a flow should work, and foreseeing behaviors for most edge cases, you are empowering yourself to defend your concepts and ideas when they will be challenged by the development team. There is nothing more frustrating than to see your product not behaving the way you imagined, because you didn’t foresee a particular scenario when preparing the wireframes. Always be two steps ahead, and put that extra effort in to make sure that the full experience was catered to. This will pay-off down the line.
- Better communicate with your developers : If you are in the situation where you are working hand-in-hand with the team who will build your product, it is necessary to be able to have an educated conversation with your developers when questions arise. Their comments will cover things you hadn’t thought of yet, and is valuable feedback to incorporate in your way of writing. Moreover, you will gradually better understand the effort required to build each story you wrote, and you will become better equiped to plan sprints if the opportunity arises.
- Accelerate testing efforts : This follows-up the advantage of being able to communicate with developers. It is plain simple: something that is well described will be well built later down the line (hopefully!). This will also lead to less bugs related to lose ends in the user interface. Let’s be honest, as a service designer, there is so much you can do to avoid bugs. Nevertheless, let’s strive to do our best to help out all members of the value chain!
In my experience, a good user story logged in a backlog needs to gather the following elements :
- The story : Captures the description of the feature from an end user perspective.
- The Gherkin model : Consists in a human-readable language for system behaviour description. It gives a consistent approach for reviewing all scenarios, defines the definition of Done, and provides crisp acceptance criteria.
- The acceptance criteria : Provide a clear description that will define the value proposition, user flow or characteristic of a story.
The technical specifications are one level of detail that I never covered, as a specific technical analyst needed to pick up the story to complete it. But if you manage to write all these elements for your story, you’re already halfway in creating something pretty solid for your developer to groom!
Fluid collaboration between all our profiles is the cornerstone of our Digital Transformation Methodology. How do you make sure that your profiles all speak the same language? Tell us in the comments down below and let’s start the conversation!
