Wonderflow

We collect user stories in many different ways; it could come directly from a client, an internal team member, or any person who uses the product. We usually try to investigate why the person is asking for a specific feature or why they are complaining about something inside the product.

Once we clearly understand what and why the person needs, we define a user story as a record inside an Airtable table. This will be formulated as an easy statement "as a user I want..." and we provide additional context in the other table fields so that when we start to work on it we can recall who asked for it and the reasons they had.

We worked on two weeks sprints on tasks defined on a Trello board composed by a link to the user story/s connected to it, the task category, and the members that will have to work on it.

The assigned cards are discussed with the Design Lead during the sprint planning. In this meeting, we allign on the expectations and the feasibility of every assigned task.

Once I got my tasks, I started to plan how to solve them, starting by defining the people I have to involve in the process to collect additional information before I start with the actual design process.

Once the scope of the design is well defined and I have organized the work to complete the task, I usually start the design process by analyzing the current situation in the app, then when I understand the pattern to adopt, I begin to sketch on paper a possible solution.

When I have my first draft, I start to do some UX research on similar patterns that I saw or found in other apps. Once I analyzed them, I compared them with my first draft and sketched a new version of it, including others solutions.

If I reach a stage on paper where I think that the solution could work, I move one to design an actual prototype on Figma. We directly design a high fidelity mockup and skip the wireframing part because of the available time. Composing the Ui with the Wanda DS is relatively fast and smooth.

When the prototype is finished, we passed over the validation process, which is variable and can have different stages. Usually, there is always a design review inside the design team to have a second opinion and double-check that there are no strange or wrong behaviors.

Once we are aligned in the design team, we start to test it, mainly with internal teams members, rather by having 1&1 or group sessions with them. For "quantitative" data instead we use Maze design to test the feature, usually, we have 20–30 participants split into two groups to perform an A/B test.

If during any part of the testing phase something fails, we investigate the reason and start the design process again by either making some changes or starting from scratch.

When the prototype had been tested successfully, we passed to the communication part. We talked with developers explaining the feature in detail then we moved on the PM and CSM teams explain the functionalities to give heds up.

When everyone is aligned we moved to the requirements writing part, we use Atlassian Confluence pages to describe the feature in detail, providing explanations on the edge case handling and all the required assets.

During the three years, I also worked on many graphic design-related projects for Wonderflow. I designed posters, t-shirts, conference stands, marketing collaterals like LinkedIn post templates, and many others. The works I'm most proud of are two logos for two wonderflow projects, Wonderwork (survey collection app) and the Wonderflow NLP academy (e-learning platform), which you can see down below.