![]() ![]() And, we hate to break it to you but it’s likely never going to feel good enough! Embrace the true iterative nature of software design and development, and make a plan for how you can continue to iterate on your design system. Need advice on how to do this effectively? Check out the blog post we just wrote on reducing silos between your development and dev teams. ![]() Communicate what has changed, and learn their language. Stop only living in Figma! Get involved with the dev team.Use the design system as your source of truth. Stop designing with components that are ahead of the state of production.They are working within your system every day and are likely to know where there are obvious gaps. Schedule some time with an engineer, listen to the challenges they are facing and inconsistencies they’ve noticed.Hot tip: if you don’t know where to start, look at usage data to know which components are essential to the user and start there. If you don’t have access to a development library, such as Storybook, the best way to find out what your engineering team is dealing with is by diving into the repository. It’s so important for designers (especially those designing systems) to learn the technical aspect of your component library. Taking a closer look at this helped us learn what terminology we were using, what was working, and what wasn’t. what we thought we had available in our library. The team was shocked at the inconsistency between how many colors existed in production vs. We pulled out our color library for everyone to take a good look at.Here’s what our team did to solve our problem. However, we knew this work needed to be done sooner rather than later to make room for dark mode. While the challenges in our design system were obvious, finding the time to retroactively go back and amend these issues was the true challenge. Regardless, our design system structure was becoming a blocker to our development teams being able to ship faster. Like many other fast-growing companies with a small but scrappy design team, there was no time (or budget) to spend resources on updating our design system. This became a problem for our development teams as refactoring components creates added risk and could make QA difficult since the component that should be tested in production may not meet the expected behaviour. ![]() Meaning, our design system had the patterns the design team wanted to be implemented in the product but weren’t in production yet. Challenge 2: Our design system didn’t match what was in productionĬomponents in our design system were ahead of production. Our color library was out of sync with production, sometimes we would use hex codes and developers would have to find the variable. Before long, you’re left with design debt that’s significantly slowing down development time, creating bottlenecks, and doubling the workload.įor full transparency, here are the two main issues we recognized within our own design system. And even though we have feedback sessions with developers to discuss complexity and project scope, sometimes our design can stray from what’s in the design system. How did this happen? As designers, it’s natural that we want to design with the best user experience in mind. When looking at our design team’s process, it was obvious we had design debt, meaning, our component library in Figma was off from what you’d see in production. Identifying current design system challenges In this blog, one of our Senior Product Designers, Mayra Pulido, will walk you through our approach, what we learned, and some best practices your team can adopt when theming for dark mode. We learned some tough lessons along the way, so we thought we’d compile them for you. Clean up our design system to make way for dark mode. The time for dark mode was now! But when we went to update our design system to allow for theming, we realized that we had some major design debt. And as users of our own product, it’s something our developers would have loved to see! So, even we’ll admit it seemed a bit bizarre that ZenHub didn’t have dark mode given that we’re a developer-focused product. Whether it’s because it looks darn cool, eases eye strain, or matches the moody feel of a dark coding dungeon (cough, home office, cough), dark mode is a tried and true fan favourite of app theming. You’d be hard-pressed to find a developer that doesn’t prefer dark mode. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |