"Documenting design decisions as a designer along the design process" I am not sure if you've written an article around this but if you haven't, then would love to know your thoughts on this.

— Asked by Vaibhav

I thought about it for many years. But find it pointless now to even try. These decisions are too rapid and contextual to document. If something needs recalling, we typically look at the revision history on Figma and remember some, call someone and ask. It's the only path of least friction and fast turnaround.

We made an attempt though! With 50 design cheat codes, we tried to publish some out of 100s that we documented. We're proud of it. But… it's obsolete now.

If you're really interested in doing it, probably the best way to document all thoughts around a feature/ project release in short, consumable format. Imagine Airbnb's Summer/Winter release for the team's work.

How does your design team at UC observe and understand user feedback and queries? Is there a workflow in place where the design team can identify whether a user issue is related to a particular UX, and then address it? How do you manage this process at scale?

— Asked by Ankit

A bunch of things:

• We occasionally do detailed usability tests of our existing real-estate on the app (flows, screens)

• We regularly shadow our partners on their jobs to meet customers as well as understand services in action

• We keep monitoring the issues raised by partners and customers on our Help portal, App store/Play store, or on Amazon.

• We use our services and products a lot to build first-hand opinion

• We are constantly in observation mode to keep an eye on new learnings

• No specific workflow. If during any of the above we find a usability problem or copy problem or feature problem etc., we simply raise it to the respective team or individual

• We document a lot of these in respective sharp documents and share them with larger groups. In addition, we try to record the entire process and share those as well so the team can then self-serve this activity when required.

How do you balance product-led design projects with design team-driven initiatives, such as design system updates or design hygiene improvements? While it's generally understood that product priorities take precedence, do you follow any practices that allow you to equally prioritise and push design-led changes?

— Asked by Ankit

Product priorities are generally the overall mix bag of problems & the respective solutions. The solutions are typically in the form of a feature release, logic handling, supporting a new use-case, opportunity to fix an earlier version, doing something new altogether. With this in context, we prioritise overall product priorities over any functional priorities.

Design, Engineering etc. are functional departments in the traditional sense. They'd each have their focus areas and priorities. These priorities are baked in the plan over the quarters in a year.

Equal prioritisation to push just design-led changes don't make sense. Similar to equal prioritisation to just push engineering-led changes won't make any sense either.

E.g. Design system implementation, transaction journey revamps are design-led changes. But, they only become priority when scaling across categories and conversion growth become priorities.

E.g. Back-end re-modelling of matching a partner with a customer request is engineering-led change. But, it only becomes priority when we introduce multiple, new ways for customers to book and schedule across different categories of services.