Design Workflow Optimization

I have spent hundreds of hours analyzing design systems. One of the things that confused me for many years is how to structure color scales and tokens. I have experimented with multiple structures at different sizes of design systems, and at a high-level recommend the following approach: 1. Primitive Colors Your design system foundations should always start with a full color scale that is based on your brand identity. We call these colors Primitives, and your variable/token collection should look like this: - purple-600 - purple-500 - purple-400 - And so on.. To create a Primitives palette you will want to start from your main brand colors and use a tool like UIColors, Supapalette, Colorbox to expand to the full scale. (links in comments) This is a great foundation to have, as it gives you a set of shades that can be used in different ways, and ensures all of them have consistent hues, saturation and brightness. However, Primitive colors are simply not effective when used directly in your designs: - They create ambiguity - Their names have no contextual meaning - They are often misused due to similarity If you have had the “why are there 20 different shades of gray?” conversation with an engineer, you know what I mean. So let’s see how we can improve that. 2. Semantic Colors This is my default recommendation to all product design teams that don’t have a highly complex design system. What you will want to do here is create a new variable collection named Semantic, which is what’s visible in your design files, and comprises of: - Brand / Action - Text - Link - Border - Icon - Surface / Background - Bias - Data / Charts Each color should point to a primitive value, e.g. - text-primary → gray-800 - text-secondary → gray-600 - text-tertiary → gray-400 This takes a bit of setting up, but creates immense long-term value. A great example of a simple, theme-level Semantic structure is Shopify’s Polaris (link in comments) 3. Component-level Semantic Lastly, if you are working on a design system with a lot of complexity and, ideally, a dedicated design systems team, you might want to add another level of hierarchy and specify colors at a component-level. In this structure, you would want to create color tokens based on how they are used in each component. - input-text-filled → text-primary - input-text-placeholder → text-secondary - input-text-disabled → text-tertiary This eliminates all guesswork, but also increases the complexity exponentially. It does serve a purpose though. As design systems scale, you may find that: - A theme-level semantic structure is too restrictive - There is still some guesswork - Decisions need to be documented. An example of this is Uber’s Base and Adobe’s Spectrum design system, linked in the comments. I’m curious to know, what structure are you using for your design system and what has worked well for you? — If you found this useful, consider reposting ♻️ #uidesign #designsystems #productdesign

🦜 “How We Fixed Skyscanner’s Broken Color Palette” (https://lnkd.in/erqd-yCX), a practical case study on how the Skyscanner team fixed their color palette — along with process, naming, testing and explorations to get there. Neatly put together by Adam Wilson, via Anna Palgan. ✅ Set your base colors: primary, secondary and UI states. ✅ Define core color pairings and extended pairings. ✅ Choose product-specific colors, gradients, patterns. ✅ 4 color groups: neutral, white text, black text, yellow/orange. 🚫 Avoid poetic names: they are difficult to remember and refer to. ✅ Mix black and grey with primary color for a better design fit. ✅ Choose a night color that is slightly lighter than black. ✅ Your colors will need to appear on different backgrounds. ✅ Create color sets with transparency for such cases. ✅ Create tints based on the color contrast against black. ✅ Create shades based on the color contrast against white. ✅ Test for color contrast, colorweakness, colorblindness early. ✅ Double-check the dark yellow problem in your palette. --- 🌱 Useful Guides How To Design A Color Palette For Design Systems, by Alex Baránov https://lnkd.in/epJkT252 How To Set Up Color in Design Systems, by Nathan Curtis https://lnkd.in/e48aJaGb How To Create An Accessible Color Palette, by Stéphanie Walter https://lnkd.in/eUnSTYSM “Dark Yellow Problem” In Color Palettes https://lnkd.in/eS7YqfCf --- 🪴 Useful Case Studies Contentful: https://lnkd.in/edHpghSj, by Fabian Schultz Goldman Sachs: https://lnkd.in/e28Fxuuv Modern Health: https://lnkd.in/ez7xM5xt, by Brian Cleveland Stripe: https://lnkd.in/enaXpWvD, by Daryl Koopersmith, Wilson Miner Wise: https://lnkd.in/eyv8Qh7r, by Stephanie S. Wish: https://lnkd.in/eGYGa7PK, by Taamannae Taabassum --- 🍭 Color Palette Generators ABC: https://lnkd.in/e7QHC2gx Accessible Palette Generator: https://lnkd.in/ejkpyWqZ Colorbox: https://colorbox.io/ Contrast Grid: https://lnkd.in/e6sENdRW Figma Color Palettes: https://lnkd.in/et2zeUjX Leonardo: https://leonardocolor.io/ Naming colors: https://lnkd.in/e6jJzRdW OKLCH Color Converter: https://lnkd.in/esP29Jyj Primer Prism: https://lnkd.in/ekpTmkkM Poline: https://lnkd.in/eSwuXW5P 👍 Stark: https://www.getstark.co/ HUGE thanks to all the wonderful people who worked and shared their insights here for all of us to use and learn from! 👏🏼👏🏽👏🏾 If you also struggle with color, hopefully that’s a good foundation to start with. What techniques, guides and tools do you use to design color palettes? Share what has and hasn’t worked for you in the comments below! 🙏🏾 #ux #design

Don’t Automate Complexity... Simplify and Error-Proof Instead When problems arise, it’s tempting to think automation is the magic fix. But automating a broken or complex process just means you’re speeding up the production of errors. The smarter approach? Simplify the process and error-proof it (Poka Yoke) before thinking about automation. Here’s why simplification often beats automation and how you can apply it. Why You Should Simplify Before Automating: 1️⃣ Faster, Cheaper Improvements Simplifying a process through standardization and removing unnecessary steps often solves problems more quickly and at a lower cost than automation. 2️⃣ Avoid Automating Waste If your process is full of waste (like waiting, overprocessing, or rework), automating it only speeds up inefficiency. Fix the process first, then think about automation. 3️⃣ Built-In Error Proofing With Poka Yoke solutions (like jigs, fixtures, or guides), you can design processes to prevent errors from happening in the first place—without needing expensive sensors or software. 4️⃣ Flexibility and Adaptability Simplified processes are easier to adjust and improve, while automated systems can be rigid and costly to change once implemented. How to Simplify and Error-Proof a Process: 🔍 Map the Current Workflow: Identify unnecessary steps, bottlenecks, and areas prone to errors. ✂️ Eliminate Waste: Remove any steps that don’t add value to the product or service. 📋 Standardize Work: Create clear, repeatable instructions that everyone can follow. 🔧 Introduce Poka Yoke: Physical Error-Proofing: Use jigs, fixtures, or alignment guides to prevent incorrect assembly. Visual Cues: Use color-coded labels or visual templates to guide operators. Sensors or Alarms: Only when needed, use low-cost technology to detect errors in real time. Example of Simplification and Poka Yoke in Action: A warehouse team was dealing with frequent errors when picking products for orders. Instead of implementing a costly automated picking system, they: 1. Introduced a color-coded bin system (Poka Yoke) to help operators select the correct items. 2. Simplified the picking route to reduce unnecessary walking and waiting time. Result: Picking errors dropped by 80%, and productivity increased by 15%—all without expensive automation. When to Consider Automation: Once the process is simplified and stabilized with minimal variation, automation can enhance speed and efficiency. But it should support an optimized process, not mask its problems.

Design systems are the domain of designers, but as product managers, we should care deeply about them too. Why? 🧐 Because they're not solely about reusable UI components; they're a vital asset that enhances efficiency, consistency, and innovation across the entire product team. Let's break it down. A design system is a comprehensive guide that includes design principles, visual design patterns, UI components, and usage guidelines. It's like a playbook for creating and maintaining the product's user interface. But its benefits extend far beyond the design team. For developers, a design system acts as a shared language. It streamlines the development process by providing ready-to-use components that fit seamlessly into the product. This reduces the time spent on UI development and ensures that the end result is consistent with the product's brand and user experience standards. Developers don't need to reinvent the wheel for each new feature, which means they can focus on solving more complex problems and delivering value faster. For product managers, design systems enable us to bring products to market more quickly and with fewer resources. By leveraging a design system, we can ensure that our products are not only visually appealing but also user-friendly and accessible. This consistency builds trust with our users, as they can navigate our products with ease, knowing what to expect from each interaction. Moreover, design systems facilitate better communication and collaboration between designers, developers, and product managers. They serve as a single source of truth that everyone can refer to, reducing misunderstandings and ensuring that everyone is on the same page. This alignment is crucial when we're working to achieve specific outcomes and need to make sure that every part of the product is contributing to those goals. But perhaps the most compelling reason for product managers to care about design systems is that they allow us to be more responsive to user needs. With a design system in place, we can quickly iterate on our products based on user feedback without compromising on quality or consistency. This agility is key in today's fast-paced market, where user expectations are constantly evolving. In short, design systems are not just a tool for designers; they're a strategic asset for the whole team. As product managers, we should champion the creation and maintenance of design systems because they help us deliver better products, faster and more efficiently. They're a critical component in becoming truly product-led and outcome-focused. So let's embrace design systems and use them to our advantage. Our teams, our products, and our users will thank us for it. What has been your experience with integrating design systems into your product development process, and how has it influenced the efficiency and effectiveness of your team's work? Let's start a conversation! #ProductInstitute #ProductManagement #UXFundamentals

Client: “This WASN’T what I had in mind…” 😬 Weeks can go by before the client sees ANY PROGRESS, leaving them uncertain, worried, and anxious about the direction the designer has decided to take. When then presenting the work, this can lead to misalignment, wasting both the client's and the designer's time, and possibly requiring the project to start over. From experience, there shouldn’t be a significant lack of communication between the start of the process and the presentation. Instead, give your clients confidence, clarity, and peace of mind by maintaining a structured and collaborative path. Here's how we can give clients peace of mind by taking a collaborative approach: 1️⃣ Brand Identity Questions – Understand the client's challenges and vision from the start. 2️⃣ Strategy Call – Align on objectives and direction. 3️⃣ Moodboards – Collaborate on the aesthetic direction. 4️⃣ Brand Development & Design – Design with the right understanding and approved creative direction. 5️⃣ Branding Proposal Presentation – Present with confidence. 🎯 By involving clients at each step, we ensure alignment and achieve results that exceed expectations. 😍 There will be times when what you present does not completely hit the mark, and that's okay. This is an opportunity to collaborate further and get closer to the ideal result. Don’t leave your clients in the dark. 💡Give your clients the confidence they deserve, and together, you'll do your best work. 🤝 🚀 Have a good Thursday. ☕️ 🎥 A little Throwback video today as things are busy behind the scenes. New videos and completed rebrands coming next week. #Branding #logodesigner #LogoDesign #GraphicDesign #GraphicDesigner #BrandGuidelines #BrandStrategy #branddesign #BrandDesigner #adobe #logodesigners #cleandesign

"We don't have time for design." The CEO was 6 weeks behind on every release. I asked one simple question: "How many times did your team rebuild the login flow this year?" He checked. Four times. ↓ Every feature was built from scratch. Every release broke something old. Every week, support got the same confused questions. His team wasn't slow. They were stuck rebuilding the same things over and over. ━━━━━━━━━ Here's what we did: Stopped building custom everything. Started building reusable blocks. 3 simple systems: → One navigation (works for all features) → One onboarding flow (copy and reuse) → One error system (users know what to do) Like LEGO blocks instead of building a new toy every time. ━━━━━━━━━ 8 weeks later: ⚡ 6-week releases → 3 weeks ⚡ Support tickets down 64% ⚡ Testing time cut in half The CEO's message: "Devs are now asking for design BEFORE they code. First time ever." ━━━━━━━━━ The lesson? You don't have time NOT to design systems. Every sprint without them costs you weeks in rework. Fast-growing teams don't custom-build everything. They build once, reuse forever. Ask your dev team today: "What do we keep rebuilding?" That's your first system to create. Drop "TIME" below if you want my 2-step roadmap to stop the rework cycle 👇 #ProductDesign #StartupGrowth #TechLeadership

Task >> Flow >> Order >> Ritual >> Rite When does reflection turn to over-analysis, stifling creative flow? And where does routine become a crutch, preventing innovation? On workflows; a measure of salt I do think (muse on idea) of workflows along a continuum: task → flow → order → ritual → rite. This progression marks the journey from completing isolated tasks to forming intentional, value-driven rituals. How I see them, at work: Task: Fundamental units of work Flow: Alignment of tasks Order: Structuring of flows into sequences Ritual: Habitual yet reflective practices Rite: Finality of a ritual Moving from task to rite invites a designer to shape his/her routine around intentional values rather than mere productivity. (analysis paralysis laughs in shadows) Now comes what, when, where & how? Tasks that occupy your day-to-day work. Group similar tasks to see if patterns emerge. E.g.: Are you frequently adjusting components in your design system? This could indicate a lack of standardized elements in your toolkit. (superficial e.g.) Post that, have a look at the flow between them. Ask: Is there a smooth transition (do you feel a lot of energy needs to be invested)/ do certain points break the flow? Energy >> Scale. E.g.: A common pitfall is rushing transitions without considering whether they add or detract from user experience. If your workflow is orthodox, consider opportunities for flexibility. Are there points where you can adapt based on feedback or new ideas? E.g.: A room for iteration may foster creativity and allow you to respond to insights rather than locking in the same trap. Rituals can help you maintain consistency while incorporating introspection. E.g. A weekly review slot to examine user feedback or usability testing results can become a valuable ritual that reinforces quality. Note: Reflective rituals should be structured yet light enough to avoid over-analyzing. Rites arise when routines start aligning with your personal or organizational design principles. At this stage, you’re no longer just following steps; you’re working with a sense of purpose and deeper connection to your craft. I still do have a lot of work to put into bringing a balance between what seems intuitive at the moment & weighing in what I have learnt. A sketch of how I try to implement that: Box time slots specifically for workflow analysis to prevent analysis from leaking into creative time. Use feedback loops with colleagues or users to identify workflow pain points and blind spots to reveal areas where habitual practices may need reassessment. I have often fallen into the trap of constantly adjusting design tools and methods. For now, I set a timeframe for adopting new tools or making significant process changes. (revisions, periodically, in general). So where does it end? I will ask does it contribute to user value?: Is it adaptable?: Does it reinforce design principles? Image Courtesy: Volunteer

When it comes to managing design systems in Figma, there’s an aspect I’ve noticed trips up a lot of beginners: Figma doesn’t technically have “design tokens,” but you can absolutely create and manage them using Figma’s variables. In practice, design tokens are named values for things like color, typography, spacing, and more. Designers like them because they’re reusable, consistent, and easy to hand off to dev. Basically: Your design decisions made once and then applied system-wide. In Figma, variables let you define visual styles once and apply them everywhere. So instead of coding #D84F2B as the background color for every button, you use a variable like ‘color.primary’. Here’s how design tokens help: ✅ Consistency: Every component pulls from the same source ✅ Scalability: Make a change once, and it updates everywhere ✅ Dev collaboration: Variables make your design language exportable and codable How to get started: 1. Set up variables for core values (color, type, spacing) 2. Name them clearly (ex: color.text.secondary) 3. Apply them across your components Optional: Use a plugin like Tokens Studio to connect with dev tools. If you’re building or maintaining a design system, using variables to manage design tokens is the key to scaling without chaos. Start small. Stay consistent. And name your tokens like future-you has to live with them. Still wrapping your head around variables? Or love them already? Let’s compare notes below. 👇 #FigmaFriday #Figma #designsystems #uxdesign #uidesign #productdesign #webdesign #variables #uxui ⸻ 👋 Hi, I’m Dane—sharing design guides & strategies. ❤️ Found this helpful? 'Like’ it to support me. 🔄 Share to help others (& save for later). ➕ Want more? Follow me for free DAILY insights.

2025 has been a BIG year for me, both in terms of what I've produced and what I've built. But it's also been two back-to-back quarters of steep learning curves. Here is my most difficult one and my lessons (and subsequently-developed processes) from it: 👉 Aligning research report design with content (and vice-versa) is harder than it looks 👈 You start with a project brief and brand guide and ensure that the final design stays within the guidelines. Seems straightforward enough, right? It's not. It's messy and requires WAY more iterations than written content does. Here's how I've learned to make it work: 👉 1. My team produces an initial design concept which includes the layout, text hierarchies, 2 data charts/visuals, and the table of contents. 👉 2. We ship this off to the client for feedback and create a checklist of edits. 👉 Meanwhile, I review the report narrative again with the design in mind—checking for pacing, repetition, and places where the visuals can do the talking. (This is where most rewrites happen.) 👉 Once the feedback is in, we refine the concept and finalize visuals. 👉 Before layout begins, I lock in the content version that aligns with the flow of the design. This means that while small edits might still happen later, the major storytelling structure is final. 👉 Layout is done in phases, not all at once. That way, we can course-correct early (usually after 5–7 pages) and avoid a total rework at the end. 👉 Finally, before sending to the client, I do a read-through as a reader—does it feel skimmable? Do the visuals support the argument? Is anything visually overwhelming or underwhelming? This workflow isn’t perfect, but it’s made a massive difference in both design quality and team sanity. If you're also in the business of creating large content assets (reports, guides, handbooks)—don’t sleep on design alignment. Do it early, do it often, and work with someone who *gets it*. A design project I'm super proud of 👇 (The HockeyStack Benchmark Report)