Not everything in the life of a designer is perfect designs and things to be proud of. Part of the hard and valuable work of the product designer's job is to understand that the product is much more than a couple of flows, and proposing big changes is not always possible and not always necessary.
CONTEXT:
Working at Rappi, I was part of the largest squads. The Core Squad (which is the one with the most flows within the SoyRappi App) and in parallel with the Picking squad where the flows related to the products (of the orders) that can appear for the delivery person (in Soy Rappi) and for the shopper (in Soy Shopper) are worked on. Normally I do everything from research (with or without the accompaniment of a researcher) through the handoff with development, to the follow-up with QA.
My work on these fast-paced products tends to be:
-
Large projects (3 weeks or more - redesigns, complex flows, etc.)
-
Small projects and one-off improvements (that can be done in a day or a week, from changing a copy, improving a component, to a short flow)
CHALLENGE:
Personally speaking, I love doing redesigns because I can propose changes to everything that, based on my experience, I consider needs to change, from copies, components, improving old elements, and even flows from start to finish.As a product designer, I have encountered:
As a product designer I encountered::
-
Old designs that look bad
-
Developments that don't look like the design
-
Screens that worked and looked good in production but after a while we realized they were wrong (through the use of the App, a live or someone from Ops or product))
Work Team:
Katherine Moreno
(Product Designer)
Firas Al-ashram
(Product Lead)
These stories started to be created with the initiative of the Core PL so that improvements could be proposed and created from the design side and not just from the product side. I am grateful for this opportunity because it has made me see and understand better from the business side and not just from the visual side.
What do these stories cover?
As a designer and presenter of the task or change request, my responsibilities was:
-
Explain the story and its details at the corresponding ceremonies.
-
Work hand in hand with the DEVS, sometimes even before making the proposal (consult them since they know and understand the technological scope much better) and may even have better things in mind.
-
Clarify any doubts that arise during development.
-
Be the approver of the final development, and curate it with the help of QA.
 |  |  |  |  |
|---|---|---|---|---|
 |
How is this different from a “regular” story proposed by the Squad Product Owner?
I take ownership of the proposal and make sure it's worth it for our developers to move this story forward. The main goal is to improve the user experience, keep the entire interface consistent, and select all existing flows to improve when the team has time for those small improvements.
GENERAL LEARNINGS
It was a very rewarding and quite long process that makes feel lucky and proud:
-
I appreciate this opportunity because it made me see things from the business side and not just from the visual side.
-
It's great to have the confidence in the product to propose improvements.
-
Several methodologies preach about fast and short iteration but many of us have resisted "just making small changes".
-
Realizing that design vision is important for development, and how this generated more approach, more credibility and in turn more effort to do things better and consult design about decisions.
-
Having a more cross and more real look at the product, as a living product.