Senior UX Designer, Design System
for section headings. Use - for any list of duties/requirements/benefits. Use
for prose.
We must include a section only when posting has real, specific content. Avoid filler like "commensurate with experience". Not present.
We must remove boilerplate: cookie/navigation/legal/EEO/equal-opportunity/scam-warning, duplicated lines, application instructions. The Fine Print includes some schedule info: "To help new team members get off to a strong start, this role will work in a Ryan office three days per week during their first 60 days. After that, it will adapt to a minimum of one day per week based on the needs of the role, team, and individual". That's schedule info. Also "Occasional travel of up to 10% may be required". Also "Work is primarily computer-based, with regular collaboration across teams, clients, and vendors". Also "This role does not have direct supervisory responsibilities but may delegate tasks to junior team members". That's fine.
We also have "Locations preferred: Dallas, Austin, or Burlington (MA)". That's location info maybe part of schedule? Could be separate but not required heading. Could include in a short p.
We have "Compensation Pay Transparency" with salary ranges per state. That's pay section.
We have "Why Ryan? Hybrid Work Options Award-Winning Culture ..." That's basically benefits and culture. We'll put Benefits section.
We have "Perks & Culture" paragraph: "Unlimited PTO, robust 401(k) match, and comprehensive benefits Growth opportunities within a collaborative, forward-thinking UX team Flexible work environment with ample opportunities for professional development". That's also perks.
We need to avoid duplication. We'll combine benefits and perks maybe.
We need sections: About Us (maybe heading About Us), The Role (maybe heading About the role? The instruction says use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we should use those exact headings where applicable. So we need sections: About the role (maybe corresponds to "The Role" description), Responsibilities (maybe "How You’ll Contribute" broken into Influence, Collaborate, Deliver), Requirements (maybe "Experience What We’re Looking For"), Qualifications (maybe "Skills"), Benefits, Pay, Schedule. Also we could have About Us as a section? Not in list but could be included as a heading? The instruction says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings, but says use those for those categories. Probably we should stick to those headings where we have content. We have About Us content; we could put that under About the role? Actually About the role is separate from About Us. But we could treat About Us as a brief intro paragraph before sections. The instruction: "Do NOT repeat the job title as a heading (the page already shows it)". It doesn't forbid having an About Us heading. But to be safe, we could include a
for About Us without heading, or use
About the role? Might be confusing.
Better: Use headings exactly as needed: About the role (for description of role), Responsibilities (for How You’ll Contribute), Requirements (for Experience), Qualifications (for Skills), Benefits (for benefits list), Pay (for compensation), Schedule (for work schedule/location/travel). Also we could include a brief About Us paragraph before headings as plain
.
We must not invent sections with filler. Ensure each heading has substantive content.
Let's extract content:
About Us paragraph: "Ryan, LLC is a global leader in tax services and technology solutions, recognized consistently as one of the Best Places to Work by Fortune and Glassdoor. We help clients unlock capital, enabling growth, investment, and innovation."
That's substantive.
The Role paragraph: "We’re seeking a Senior UX Designer, Design Systems to own and evolve the design system that powers our suite of digital tax products. You’ll be the person who keeps our components sharp, our patterns consistent, and our system scalable as the product grows. This is a craft-first individual contributor role for a designer who obsesses over the details others overlook: token naming, component behavior, documentation clarity, and the kind of systematic thinking that makes a design system usable at scale. You have UX breadth to understand how the system serves the products built on top of it, and technical curiosity to collaborate fluently with the engineers who consume it. *All candidates must include a digital portfolio or link in their application.*" The last sentence about portfolio is application instruction; we should remove application instructions. So remove "*All candidates must include a digital portfolio or link in their application.*". Keep rest.
Responsibilities: How You’ll Contribute sections: Influence, Collaborate, Deliver. We'll combine into a list of duties.
Influence bullet points:
- Be the go-to authority for our design system, setting and maintaining the standard for how components are built, named, documented, and used across the team
- Educate and support designers across the team on system usage, contributing to a culture where the design system is understood, trusted, and consistently applied
- Identify gaps, inconsistencies, and debt within the system, prioritizing and advocating for improvements that have the highest impact across the product suite
Collaborate bullet points:
- Work closely with Engineering to ensure design system components translate accurately into code, maintaining a tight feedback loop between what’s designed and what’s built
- Partner with product designers to understand how the system is being used in practice, incorporating real-world feedback into how components and patterns evolve
- Engage with Product and Visual Design to ensure new patterns are grounded in real product needs and aligned with our visual standards before they enter the system
- Serve as a critical partner in design system governance, bringing the design and craft perspective to all governance discussions
Deliver bullet points:
- Design, build, and maintain a library of reusable components in Figma that are well-structured, thoroughly documented, and ready for both designers and developers to use with confidence
- Own our token and variable architecture in Figma, keeping it clean, scalable, and synchronized with what engineering is implementing in code
- Write and maintain clear, practical documentation for components and patterns, covering usage guidelines, do’s and don’ts, and implementation notes that engineers can actually build from
- Bake accessibility into the system from the ground up making compliance the default rather than an afterthought (i.e. you know WCAG, ARIA, contrast ratios, and more)
We'll put these as
- under Responsibilities.
Requirements (Experience): "Experience What We’re Looking For" paragraph:
- 5–8 years of product/UX design experience, with meaningful time spent owning or significantly contributing to a enterprise-level design system used by multiple products
- Proven track record of building, maintaining, and scaling component libraries that are adopted and trusted by product teams
- Financial, enterprise, or B2B background is a plus
- Demonstrated ability with AI tools and processes that accelerate design and research (e.g., Claude, Figma Make, Lovable etc)
We'll list as
- .
Qualifications (Skills): "Skills" paragraph:
- Portfolio or work samples that demonstrate design system thinking and execution
- Deep Figma expertise in variables, tokens, component properties, auto-layout, and library management
- Solid understanding of how design systems translate into code, with working knowledge of HTML, CSS, and component-based frameworks (React, etc.) being a meaningful plus
- Mindset: Detail-obsessed in a way that extends beyond aesthetics: You care about naming conventions, component states, edge cases, and the consistency of things most people never notice
- Thinks in systems: Able to see how a single component decision ripples across an entire product suite, and disciplined enough to make the right call even when the easy one is tempting
- Comfortable sitting at the intersection of design and engineering, able to speak both languages and build trust on both sides
We'll list as
- .
Benefits: list from top:
- Hybrid Work Options
- Award-Winning Culture
- Generous Personal Time Off (PTO) Benefits
- 14-Weeks of 100% Paid Leave for New Parents (Adoption Included)
- Monthly Gym Membership Reimbursement OR Gym Equipment Reimbursement
- Benefits Eligibility Effective Day One
- 401K with Employer Match
- Tuition Reimbursement After One Year of Service
- Fertility Assistance Program
- Four-Week Company-Paid Sabbatical Eligibility After Five Years of Service
Also Unlimited PTO mentioned later but that's similar to Generous PTO; we can include Unlimited PTO as benefit.
We'll combine.
Pay: compensation ranges per state. We'll present as a
summarizing: "Pay transparency: base salary hiring ranges vary by location (e.g., California: $124,000–$163,020 or $114,000–$149,490; Colorado: $109,000–$142,670; Illinois: $114,000–$149,490 or $109,000–$142,670; Maryland: $109,000–$142,670; Massachusetts: $114,000–$149,490 or $109,000–$142,670; New Jersey: $124,000–$163,020; New York: $124,000–$163,020 or $103,000–$135,850; Washington: $114,000–$149,490)." That's specific.
Schedule: from Fine Print: "To help new team members get off to a strong start, this role will work in a Ryan office three days per week during their first 60 days. After that, it will adapt to a minimum of one day per week based on the needs of the role, team, and individual. Occasional travel of up to 10% may be required. Work is primarily computer-based, with regular collaboration across teams, clients, and vendors. This role does not have direct supervisory responsibilities but may delegate tasks to junior team members. Locations preferred: Dallas, Austin, or Burlington (MA)." We'll put as
.
We must not include boilerplate like EEO etc. The Fine Print includes "Ryan is an Equal Opportunity Employer..." we should remove that line. Also "#DICE" at end remove.
Now construct HTML.
We'll start with a
for About Us.
Then
About the role
... (The Role paragraph without portfolio line).
Then Res
for prose. We must include a section only when posting has real, specific content. Avoid filler like "commensurate with experience". Not present. We must remove boilerplate: cookie/navigation/legal/EEO/equal-opportunity/scam-warning, duplicated lines, application instructions. The Fine Print includes some schedule info: "To help new team members get off to a strong start, this role will work in a Ryan office three days per week during their first 60 days. After that, it will adapt to a minimum of one day per week based on the needs of the role, team, and individual". That's schedule info. Also "Occasional travel of up to 10% may be required". Also "Work is primarily computer-based, with regular collaboration across teams, clients, and vendors". Also "This role does not have direct supervisory responsibilities but may delegate tasks to junior team members". That's fine. We also have "Locations preferred: Dallas, Austin, or Burlington (MA)". That's location info maybe part of schedule? Could be separate but not required heading. Could include in a short p. We have "Compensation Pay Transparency" with salary ranges per state. That's pay section. We have "Why Ryan? Hybrid Work Options Award-Winning Culture ..." That's basically benefits and culture. We'll put Benefits section. We have "Perks & Culture" paragraph: "Unlimited PTO, robust 401(k) match, and comprehensive benefits Growth opportunities within a collaborative, forward-thinking UX team Flexible work environment with ample opportunities for professional development". That's also perks. We need to avoid duplication. We'll combine benefits and perks maybe. We need sections: About Us (maybe heading About Us), The Role (maybe heading About the role? The instruction says use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we should use those exact headings where applicable. So we need sections: About the role (maybe corresponds to "The Role" description), Responsibilities (maybe "How You’ll Contribute" broken into Influence, Collaborate, Deliver), Requirements (maybe "Experience What We’re Looking For"), Qualifications (maybe "Skills"), Benefits, Pay, Schedule. Also we could have About Us as a section? Not in list but could be included as a heading? The instruction says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings, but says use those for those categories. Probably we should stick to those headings where we have content. We have About Us content; we could put that under About the role? Actually About the role is separate from About Us. But we could treat About Us as a brief intro paragraph before sections. The instruction: "Do NOT repeat the job title as a heading (the page already shows it)". It doesn't forbid having an About Us heading. But to be safe, we could include a
for About Us without heading, or use
About the role? Might be confusing. Better: Use headings exactly as needed: About the role (for description of role), Responsibilities (for How You’ll Contribute), Requirements (for Experience), Qualifications (for Skills), Benefits (for benefits list), Pay (for compensation), Schedule (for work schedule/location/travel). Also we could include a brief About Us paragraph before headings as plain
. We must not invent sections with filler. Ensure each heading has substantive content. Let's extract content: About Us paragraph: "Ryan, LLC is a global leader in tax services and technology solutions, recognized consistently as one of the Best Places to Work by Fortune and Glassdoor. We help clients unlock capital, enabling growth, investment, and innovation." That's substantive. The Role paragraph: "We’re seeking a Senior UX Designer, Design Systems to own and evolve the design system that powers our suite of digital tax products. You’ll be the person who keeps our components sharp, our patterns consistent, and our system scalable as the product grows. This is a craft-first individual contributor role for a designer who obsesses over the details others overlook: token naming, component behavior, documentation clarity, and the kind of systematic thinking that makes a design system usable at scale. You have UX breadth to understand how the system serves the products built on top of it, and technical curiosity to collaborate fluently with the engineers who consume it. *All candidates must include a digital portfolio or link in their application.*" The last sentence about portfolio is application instruction; we should remove application instructions. So remove "*All candidates must include a digital portfolio or link in their application.*". Keep rest. Responsibilities: How You’ll Contribute sections: Influence, Collaborate, Deliver. We'll combine into a list of duties. Influence bullet points: - Be the go-to authority for our design system, setting and maintaining the standard for how components are built, named, documented, and used across the team - Educate and support designers across the team on system usage, contributing to a culture where the design system is understood, trusted, and consistently applied - Identify gaps, inconsistencies, and debt within the system, prioritizing and advocating for improvements that have the highest impact across the product suite Collaborate bullet points: - Work closely with Engineering to ensure design system components translate accurately into code, maintaining a tight feedback loop between what’s designed and what’s built - Partner with product designers to understand how the system is being used in practice, incorporating real-world feedback into how components and patterns evolve - Engage with Product and Visual Design to ensure new patterns are grounded in real product needs and aligned with our visual standards before they enter the system - Serve as a critical partner in design system governance, bringing the design and craft perspective to all governance discussions Deliver bullet points: - Design, build, and maintain a library of reusable components in Figma that are well-structured, thoroughly documented, and ready for both designers and developers to use with confidence - Own our token and variable architecture in Figma, keeping it clean, scalable, and synchronized with what engineering is implementing in code - Write and maintain clear, practical documentation for components and patterns, covering usage guidelines, do’s and don’ts, and implementation notes that engineers can actually build from - Bake accessibility into the system from the ground up making compliance the default rather than an afterthought (i.e. you know WCAG, ARIA, contrast ratios, and more) We'll put these as
- under Responsibilities.
Requirements (Experience): "Experience What We’re Looking For" paragraph:
- 5–8 years of product/UX design experience, with meaningful time spent owning or significantly contributing to a enterprise-level design system used by multiple products
- Proven track record of building, maintaining, and scaling component libraries that are adopted and trusted by product teams
- Financial, enterprise, or B2B background is a plus
- Demonstrated ability with AI tools and processes that accelerate design and research (e.g., Claude, Figma Make, Lovable etc)
We'll list as
- .
Qualifications (Skills): "Skills" paragraph:
- Portfolio or work samples that demonstrate design system thinking and execution
- Deep Figma expertise in variables, tokens, component properties, auto-layout, and library management
- Solid understanding of how design systems translate into code, with working knowledge of HTML, CSS, and component-based frameworks (React, etc.) being a meaningful plus
- Mindset: Detail-obsessed in a way that extends beyond aesthetics: You care about naming conventions, component states, edge cases, and the consistency of things most people never notice
- Thinks in systems: Able to see how a single component decision ripples across an entire product suite, and disciplined enough to make the right call even when the easy one is tempting
- Comfortable sitting at the intersection of design and engineering, able to speak both languages and build trust on both sides
We'll list as
- .
Benefits: list from top:
- Hybrid Work Options
- Award-Winning Culture
- Generous Personal Time Off (PTO) Benefits
- 14-Weeks of 100% Paid Leave for New Parents (Adoption Included)
- Monthly Gym Membership Reimbursement OR Gym Equipment Reimbursement
- Benefits Eligibility Effective Day One
- 401K with Employer Match
- Tuition Reimbursement After One Year of Service
- Fertility Assistance Program
- Four-Week Company-Paid Sabbatical Eligibility After Five Years of Service
Also Unlimited PTO mentioned later but that's similar to Generous PTO; we can include Unlimited PTO as benefit.
We'll combine.
Pay: compensation ranges per state. We'll present as a
summarizing: "Pay transparency: base salary hiring ranges vary by location (e.g., California: $124,000–$163,020 or $114,000–$149,490; Colorado: $109,000–$142,670; Illinois: $114,000–$149,490 or $109,000–$142,670; Maryland: $109,000–$142,670; Massachusetts: $114,000–$149,490 or $109,000–$142,670; New Jersey: $124,000–$163,020; New York: $124,000–$163,020 or $103,000–$135,850; Washington: $114,000–$149,490)." That's specific. Schedule: from Fine Print: "To help new team members get off to a strong start, this role will work in a Ryan office three days per week during their first 60 days. After that, it will adapt to a minimum of one day per week based on the needs of the role, team, and individual. Occasional travel of up to 10% may be required. Work is primarily computer-based, with regular collaboration across teams, clients, and vendors. This role does not have direct supervisory responsibilities but may delegate tasks to junior team members. Locations preferred: Dallas, Austin, or Burlington (MA)." We'll put as
. We must not include boilerplate like EEO etc. The Fine Print includes "Ryan is an Equal Opportunity Employer..." we should remove that line. Also "#DICE" at end remove. Now construct HTML. We'll start with a
for About Us. Then
About the role
... (The Role paragraph without portfolio line).
ThenRes
- .
Benefits: list from top:
- Hybrid Work Options
- Award-Winning Culture
- Generous Personal Time Off (PTO) Benefits
- 14-Weeks of 100% Paid Leave for New Parents (Adoption Included)
- Monthly Gym Membership Reimbursement OR Gym Equipment Reimbursement
- Benefits Eligibility Effective Day One
- 401K with Employer Match
- Tuition Reimbursement After One Year of Service
- Fertility Assistance Program
- Four-Week Company-Paid Sabbatical Eligibility After Five Years of Service
Also Unlimited PTO mentioned later but that's similar to Generous PTO; we can include Unlimited PTO as benefit.
We'll combine.
Pay: compensation ranges per state. We'll present as a
- .
Qualifications (Skills): "Skills" paragraph:
- Portfolio or work samples that demonstrate design system thinking and execution
- Deep Figma expertise in variables, tokens, component properties, auto-layout, and library management
- Solid understanding of how design systems translate into code, with working knowledge of HTML, CSS, and component-based frameworks (React, etc.) being a meaningful plus
- Mindset: Detail-obsessed in a way that extends beyond aesthetics: You care about naming conventions, component states, edge cases, and the consistency of things most people never notice
- Thinks in systems: Able to see how a single component decision ripples across an entire product suite, and disciplined enough to make the right call even when the easy one is tempting
- Comfortable sitting at the intersection of design and engineering, able to speak both languages and build trust on both sides
We'll list as