Design Requirements Explained
This note translates the requirement mail into simple words.
Short Summary
Your boss wants a product designer who can do 3 things at once:
- Build a shared design system.
- Keep the user experience consistent across Mozilor products like CookieYes, WebToffee, WebYes, and BootstrapDash.
- Help the team work in a repeatable, scalable way with research, documentation, and design QA.
2.1 Design System and Standards
1. Audit existing UI/UX patterns
- What: Look at all current screens and find what is inconsistent or repeated.
- Why: You cannot create one standard unless you know what already exists.
- How: Review CookieYes, WebYes, WebToffee, and BootstrapDash screens and note differences in buttons, colors, spacing, forms, and navigation.
- Example: If CookieYes uses one style of primary button and WebYes uses another, the team should decide one shared button style.
2. Define and document a design system
- What: Create the rulebook for how the products should look and behave.
- Why: So every designer and developer uses the same language.
- How: Define typography, colors, spacing, grid, icons, motion, breakpoints, and accessibility rules.
- Example: CookieYes consent banners, WebYes dashboards, and WebToffee plugin screens should all follow the same spacing scale and text hierarchy.
3. Build and maintain the system in Figma or another library
- What: Store all reusable components in one place.
- Why: So the team does not create separate versions in different files.
- How: Make one shared Figma library with buttons, inputs, cards, tables, alerts, and modals.
- Example: If the CookieYes team updates a form field, WebYes and WebToffee can reuse the same updated field.
4. Create usage guidelines and handoff docs
- What: Explain how each component should be used.
- Why: Developers should not guess design intent.
- How: Write short rules like when to use a primary button vs secondary button, or how much spacing to keep between sections.
- Example: The WebYes audit result card should have the same layout rules every time it appears.
5. Establish versioning and governance
- What: Control how the design system changes.
- Why: Without governance, everyone makes random updates and the system breaks.
- How: Use a change-request process, version numbers, review owners, and approval rules.
- Example: If CookieYes needs a new consent banner pattern, it should be approved once and then shared across the portfolio.
How Giant Companies Do This
- Google: uses Material Design to keep product behavior and visual language consistent across many tools.
- Example: Google Calendar, Gmail, and Drive feel different in purpose, but the buttons, spacing, and overall UI still feel like one family.
- Microsoft: uses Fluent Design and shared component libraries so different teams build from the same system.
- Example: Outlook, Teams, and Microsoft 365 admin pages all reuse familiar layouts and controls, so users do not need to relearn the basics.
- Apple: keeps design extremely controlled, so product quality feels polished and predictable.
- Example: iPhone Settings, Photos, and Messages all feel tight and refined because Apple keeps the interface rules very consistent.
- Shopify: uses a strong design system because many products and admin screens need to feel like one platform.
- Example: Shopify admin pages and app screens stay visually aligned, so merchants feel they are still inside the same product ecosystem.
- Tradeoff: if a company changes the design system too fast, developers can get frustrated because old code, new rules, and rushed migrations create confusion.
- Mozilor lesson: CookieYes, WebToffee, and WebYes need one shared design language, but the change process must be calm and well-documented so the team can adopt it without chaos.
2.2 Multi-Product UX Strategy
1. Own the experience across all products
- What: Make the portfolio feel like one ecosystem.
- Why: Users should not feel like they are learning a new company every time they switch products.
- How: Reuse common patterns for navigation, settings, onboarding, notifications, and account pages.
- Example: A Mozilor user moving from CookieYes to WebYes should recognize the same layout style and menu behavior.
2. Design shared UX patterns
- What: Create one pattern for common tasks.
- Why: It saves users from relearning basics.
- How: Standardize onboarding, dashboards, billing, notifications, and settings.
- Example: CookieYes billing pages and WebToffee billing pages should work the same way.
3. Define cross-sell and upsell experience
- What: Design how users discover other products.
- Why: New products should feel helpful, not disruptive.
- How: Place relevant suggestions inside the workflow at natural moments.
- Example: A CookieYes user seeing accessibility risks could be guided toward WebYes.
4. Map end-to-end user journeys
- What: Trace the whole user path from start to finish.
- Why: To find friction, drop-offs, and opportunities.
- How: Draw the journey from sign-up to activation to retention.
- Example: Track how a WebToffee user discovers the product, completes setup, and starts using it weekly.
5. Ensure design continuity
- What: Keep visuals and flows consistent between products.
- Why: It makes the portfolio feel like a single platform.
- How: Use shared navigation, shared component patterns, and shared terminology.
- Example: A settings page in CookieYes should not feel unrelated to settings in WebYes.
6. Integrate new products smoothly
- What: Make new products fit the same ecosystem.
- Why: So growth does not create a fragmented experience.
- How: Define the UX approach before the product launches.
- Example: If Mozilor launches a new API-first product, it should still follow the same design rules and account structure.
How Giant Companies Do This
- Google: keeps Search, Workspace, and Cloud connected through shared account patterns and familiar navigation logic.
- Example: a user can move from Gmail to Drive to Docs and still understand the account and navigation model quickly.
- Amazon: makes many different services feel usable because common actions like account, billing, and notifications follow repeatable patterns.
- Example: the AWS console is complex, but the left navigation and account structure stay familiar across many services.
- Adobe: keeps creative products within one ecosystem so users can move between tools without relearning everything.
- Example: Photoshop and Illustrator share a family feel, so designers know they are still inside Adobe even when the task changes.
- Atlassian: links Jira, Confluence, and other tools with shared navigation and account experiences.
- Example: a team can jump from Jira work tracking to Confluence docs without feeling like they entered a completely different product.
- Tradeoff: cross-product consistency is valuable, but too much sameness can hide product-specific needs.
- Mozilor lesson: CookieYes should not feel like a separate company from WebYes or WebToffee, but each product still needs its own job to be done.
2.3 Product Design Execution
1. Translate complex features into simple interfaces
- What: Turn hard problems into easy screens.
- Why: Most users do not care about technical complexity.
- How: Use clear layouts, labels, and step-by-step flows.
- Example: WebYes should show website audit issues in plain language, not technical jargon only developers understand.
2. Produce wireframes, mockups, and prototypes
- What: Show the product before it is built.
- Why: It reduces mistakes and wasted engineering time.
- How: Start with rough wireframes, then hi-fi screens, then clickable prototypes.
- Example: Before redesigning CookieYes onboarding, create a prototype and test it.
3. Do competitor analysis and heuristic reviews
- What: Compare your UX with competitors and best practices.
- Why: To know where Mozilor is behind or ahead.
- How: Review how leading products handle onboarding, dashboards, and billing.
- Example: Compare WebYes reports with other website audit tools.
4. Join sprint planning and reviews
- What: Stay involved while the feature is being built.
- Why: So design intent is preserved.
- How: Review implementation, answer questions, and catch gaps early.
- Example: During a CookieYes banner release, make sure the spacing, copy, and behavior match the design.
How Giant Companies Do This
- Figma: turns complex design work into a simple collaborative interface, which is why the product feels usable even for technical workflows.
- Example: multiple designers can work in the same file at the same time and still understand who changed what.
- Stripe: is known for clear product UI and excellent developer-facing design, especially in onboarding and API experiences.
- Example: Stripe makes payments setup easier by combining a clean dashboard with strong docs and simple setup steps.
- Canva: makes advanced design tasks feel simple by reducing the number of decisions users must make at once.
- Example: someone with little design skill can still create a decent presentation fast because Canva gives templates and clear controls.
- Notion: keeps complex product behavior understandable through strong visual hierarchy and clean interaction design.
- Example: users can manage docs, tasks, and databases in one place because Notion keeps the interface light and flexible.
- Tradeoff: these companies invest heavily in refinement, so the product feels easy even when the backend is complex.
- Mozilor lesson: WebYes audits, CookieYes compliance, and WebToffee store tools should be packaged in a way that feels simple for non-technical users.
2.4 User Research and Validation
1. Run lightweight research regularly
- What: Talk to users and watch how they use the product.
- Why: So design decisions are based on real behavior.
- How: Use usability tests, interviews, session recordings, and heuristic reviews.
- Example: Watch how users set up WebYes alerts and where they get confused.
2. Define experience metrics
- What: Measure the quality of the user experience.
- Why: If you cannot measure it, you cannot improve it.
- How: Track activation, drop-off, task success, retention, and support tickets.
- Example: Measure how many CookieYes users finish setup without help.
3. Validate before engineering work
- What: Test the design before the team spends too much time building it.
- Why: It reduces expensive rework.
- How: Test high-risk changes with real users first.
- Example: Before changing WebToffee onboarding, test it with a few store owners.
How Giant Companies Do This
- Google: uses experiments and usage data heavily, so product decisions are validated at scale.
- Example: Google often tests changes with small user groups before rolling them out widely.
- Airbnb: is known for strong user research and testing before major UX changes.
- Example: Airbnb studies how hosts and guests behave before changing booking or listing flows.
- Duolingo: continuously tests onboarding and learning flows because small UX improvements can change retention a lot.
- Example: Duolingo tries different lesson and reminder flows to keep users learning every day.
- Meta: relies on large-scale experimentation, but that can also create tension when constant changes overwhelm users or developers.
- Example: Meta can move very quickly on interface experiments, which helps learning speed but can also create change fatigue.
- Tradeoff: rapid experimentation can improve products quickly, but if the pace is too high, teams may feel like they are always chasing the next change.
- Mozilor lesson: validate big changes like CookieYes onboarding or WebYes dashboards with users before engineering starts.
2.5 Team Mentorship and Capability Building
1. Mentor UX/UI teammates
- What: Help other designers improve.
- Why: A strong team is better than one strong designer.
- How: Review work, give feedback, and share patterns.
- Example: Teach a teammate how to design a better CookieYes settings flow.
2. Run regular critiques
- What: Review design work together.
- Why: It improves quality and shared language.
- How: Hold weekly design reviews.
- Example: Review a WebYes dashboard redesign as a team.
3. Identify future PMs from UX
- What: Find designers who can grow into product roles.
- Why: UX people often understand users and tradeoffs well.
- How: Give them strategy and ownership opportunities.
- Example: A designer who deeply understands CookieYes onboarding could later help own product decisions.
4. Support design-capable engineers
- What: Help engineers who care about UX get better at design thinking.
- Why: Good UX should not depend only on designers.
- How: Share design rules and include engineers in critiques.
- Example: A frontend engineer working on WebToffee can learn to spot spacing and hierarchy issues.
5. Create onboarding docs
- What: Document how the team works.
- Why: New designers, PMs, and engineers should self-serve.
- How: Write guides for design system use, review steps, and handoff process.
- Example: A new hire should understand CookieYes patterns without asking the same questions repeatedly.
How Giant Companies Do This
- Google: uses design reviews, writing culture, and strong internal documentation so teams can work without depending on one person.
- Example: teams write things down first so decisions are clear before work starts.
- Microsoft: scales capability through formal systems, templates, and cross-functional standards.
- Example: product and engineering teams can reuse shared templates instead of creating a new process every time.
- Spotify: uses autonomous squads, but still keeps shared expectations through rituals and working agreements.
- Example: squads move independently, but they still align through planning rituals and shared rules.
- Figma: benefits from a culture where designers, engineers, and product people share the same language.
- Example: a feature can be discussed in one Figma file by design, product, and engineering without confusion.
- Tradeoff: if mentorship is weak, large companies become inconsistent very fast even if they have great talent.
- Mozilor lesson: the goal is not only to be a strong designer, but to make the whole team more design-capable over time.
2.6 Process, Tooling, and Automation
1. Define design-to-development handoff
- What: Create a clear transfer from design to code.
- Why: Miscommunication causes bugs.
- How: Use annotations, component specs, and interaction notes.
- Example: The WebYes team should know exactly what happens when a user clicks an issue card.
2. Create a design-review checklist
- What: Give PMs and engineers a self-review tool.
- Why: So not every screen needs manual review.
- How: Check layout, accessibility, copy, spacing, and component usage.
- Example: Before sending a CookieYes screen to design, the PM checks it against the checklist.
3. Explore automated consistency checks
- What: Use tools to catch design issues automatically.
- Why: It saves time and improves consistency.
- How: Add visual regression tests, component linting, and accessibility checks to CI/CD.
- Example: A test can flag if a WebToffee page uses a wrong button style.
4. Use AI-assisted design QA
- What: Let AI help detect inconsistencies and accessibility gaps.
- Why: AI can review many screens faster than humans.
- How: Use screenshot comparison, accessibility audit reports, and pattern-violation detection.
- Example: AI can scan CookieYes and WebYes screens and report pages that do not follow the design system.
How Giant Companies Do This
- Google: automates quality checks aggressively so products can move fast without losing basic consistency.
- Example: product teams rely on automated checks so they do not have to inspect every tiny change by hand.
- Netflix: is known for engineering automation and strong testing culture, which reduces manual bottlenecks.
- Example: Netflix uses automated systems and engineering discipline so releases can move with less manual review.
- Amazon: uses highly structured delivery and review processes to reduce ambiguity at scale.
- Example: Amazon teams often work with detailed written updates so many people can stay aligned without constant meetings.
- Atlassian: encourages self-service through documentation, templates, and workflow tools.
- Example: Jira and Confluence let teams track work and write decisions in one place instead of relying only on meetings.
- Tradeoff: automation helps teams move faster, but too much process without clarity can make developers feel blocked instead of supported.
- Mozilor lesson: use automation to remove repeat review work, not to add unnecessary friction for CookieYes, WebYes, or WebToffee teams.
Simple Meaning Of Key Terms
- Design system: one shared set of rules and components for all products.
- Typography: the rules for text style, size, and hierarchy.
- Palette: the set of brand colors.
- Spacing and grid: how things are aligned and how much space sits between them.
- Iconography: the style of icons.
- Interaction patterns: what happens when users click, hover, type, or submit.
- Motion and animation: movement used to guide attention or provide feedback.
- Responsive breakpoints: screen sizes where the layout changes for mobile, tablet, and desktop.
- Accessibility standards: rules that make the product usable for people with disabilities.
- WCAG 2.1 AA: the baseline accessibility target the team should meet.
- Versioning: tracking updates to the design system over time.
- Governance: the process for approving and controlling changes.
- Heuristic review: checking the product against common UX best practices.
- Visual regression testing: comparing screenshots to catch layout changes.
- Component linting: checking that the right components are used.
- CI/CD: automated build and release checks.
One-Line View Of The Whole Role
This role is basically: create the rules, keep the product experience consistent, improve the quality of work, and help the team scale without chaos.
Company Examples In One Place
- CookieYes: design cookie banners, consent flows, settings, and trust-related screens consistently.
- WebToffee: simplify plugin setup, billing, and store operations screens.
- WebYes: make audit results, issue tracking, and remediation flows easy to understand.
- BootstrapDash: ensure dashboard templates follow the same design language as the rest of Mozilor.
My Learning Shortcut
If you want to remember the requirement quickly, use this order:
- Know the current state.
- Million-dollar idea: audit the real UX debt across CookieYes, WebToffee, WebYes, and BootstrapDash before inventing anything new.
- Create the rulebook.
- Million-dollar idea: build one shared design system so every product looks and behaves like one premium Mozilor ecosystem.
- Keep all products consistent.
- Million-dollar idea: reuse the same patterns for onboarding, billing, settings, and navigation so users learn once and use everywhere.
- Test with real users.
- Million-dollar idea: validate high-risk changes early so Mozilor saves engineering time and avoids expensive redesigns later.
- Teach the team.
- Million-dollar idea: turn the designer into a multiplier who raises the quality of PMs, engineers, and future designers.
- Automate quality control.
- Million-dollar idea: use design QA, accessibility checks, and AI review to catch errors before humans waste time on manual review.
- Turn friction into product ideas.
- Million-dollar idea: every repeated support issue, onboarding drop-off, or confusing screen should become a product improvement opportunity.
- Make trust a product moat.
- Million-dollar idea: CookieYes can win not only by compliance, but by making trust, clarity, and ease of use feel premium.
- Build cross-sell naturally.
- Million-dollar idea: a CookieYes user who needs site health should be guided to WebYes, and a store owner should be guided to WebToffee without interruption.
- Think like an operating system.
- Million-dollar idea: the real value is not one screen or one feature, but the system that makes every product faster to design, build, and improve.