IMAGE IMAGE
The design system needs to be a cut above. Developers use our design system as the base standard for their product engineering. But when we have a shaky foundation, we create leaky features, and UI shenanigans ensue. It's part of our job to ensure that the design specifications are accurate (building consensus with all the right people), build atomically instead of just slinging code, and think critically about our components' API. I mean, I even spent half a day just on the prop types. Kinda kidding... but also…
In a role where I work pretty much solo, I have to know when to reach out to whom. While the hard work seems like deep engineering and toggling back and forth with design studio feedback, the real work is convincing other people to take on your idea. It involves multiple demos to tech leads, PMs, engineering leadership, and back again - that's just part of the rollout!
be it product managers, designers, or engineers - allows you to maximize the utility of your time. Designers engage with the ambiguity and love figuring and testing out alternative solutions. Engineers are pumped about the project's technical complexity and interested in pushing technical limits and building bullet-proof code. Product managers focus on the applicability of your work to their product team's mandate in order to protect their teams' time so having a clear understanding of components' use cases to their business problems is paramount. Knowing who to approach and when will save you a lot of time and remove a decent amount of uncertainty regarding if you’re working on the right problem.
Previous Implementation IMAGE IMAGE Existing implementation of tables