Designer Lead

# Senior Product Designer / UX Architect for Complex SaaS Platform — Research, UX, UI and Documentation We are looking for an experienced Senior Product Designer / UX Architect to help design several major modules within a large multi-tenant business software platform. This is not simply a Figma production job. We need someone who can understand complicated business workflows, research existing products, identify better interaction patterns, organize information clearly, design the UX, create polished UI, document decisions, and confidently explain those decisions to developers and stakeholders. You may use AI as part of your workflow, but you cannot rely on AI to do your thinking for you. We expect original research, reasoning, product thinking, validation, and design judgment. ## Modules You Will Help Design Initial areas include: * Vendor Portal * Vendor Management * Resources Management * Rentals Management * Rental Offerings * Rental Offering Portal * Affiliate Portal * Affiliate Management * Work Queue * Related dashboards, detail pages, workflows, setup screens, status systems, permissions, and administrative experiences These modules are interconnected, so we are specifically looking for someone who can think in terms of systems rather than isolated screens. # What We Need From You ## 1. Product and Competitive Research We do not want to tell you exactly how every feature should work. Part of your job is to research the market and come back to us with findings. For each major module, you should investigate: * Leading platforms offering similar functionality * Direct competitors * Indirect competitors * Best-in-class SaaS products * Marketplace platforms * Vendor management systems * Procurement platforms * Property and equipment rental platforms * Affiliate management platforms * Workforce and work queue platforms * Booking and scheduling platforms where relevant * Enterprise software patterns * Modern consumer applications where they provide a better UX pattern We expect you to identify: * What competitors do well * What they do poorly * Common patterns * Missing functionality * Unnecessary complexity * Opportunities for us to simplify the experience * Opportunities for us to build something meaningfully better Do not wait for us to provide every reference. You are expected to conduct the research and present your findings to us. We want you to bring ideas to us, not simply wait for us to tell you what to design. # 2. UX Architecture Before jumping into polished screens, you need to understand the underlying system. You should help define: * User types * User roles * User goals * Jobs to be done * Primary workflows * Secondary workflows * Entry points * Navigation * Information hierarchy * Relationships between modules * Status models * Permissions * Empty states * Error states * Approval states * Setup and configuration experiences * Administrative experiences * External portal experiences * Internal staff experiences For example, a Vendor Portal may involve: Vendor invitation → onboarding → profile setup → qualification → requests → RFPs → bids → proposals → assignments → work completion → documents → communication → invoices → payments → performance → ongoing relationship. We need a designer who asks: What is the mental model of this system? Not simply: What should this screen look like? # 3. User Flows We expect detailed user flows for important workflows. Flows should show: * Where users start * Decisions they make * Required information * System actions * Human actions * Permission checks * Approvals * Notifications * Exceptions * Alternate paths * Completion states * What happens next Where appropriate, include: * Happy paths * Edge cases * Failure states * Empty states * First-time user experiences * Returning-user experiences We do not want only the ideal scenario designed. The designer should think through what happens when something goes wrong, when information is missing, when permissions differ, when an organization configures the feature differently, or when a user does something unexpected. # 4. UI Design The interface still needs to look excellent. We want a modern SaaS experience that feels: * Professional * Modern * High quality * Clear * Fast * Intuitive * Visually differentiated * Appropriate for both small businesses and enterprise organizations We do not want generic AI-generated dashboards where every page contains: * Four KPI cards * A random chart * A generic table * Identical cards * Excessive gradients * Decorative elements that do not improve usability The interface should come from the workflow. If a workflow needs: * A table * Kanban * Timeline * Map * Calendar * Queue * Stepper * Drawer * Workspace * Command bar * Status tracker * Split view Use the pattern because it solves the problem, not because it looks trendy. # 5. Design the Entire Experience We need thorough designs, not one attractive dashboard per module. For a module, this may include: * Dashboard * List or index page * Detail page * Create flow * Edit flow * Search * Filters * Sorting * Saved views * Bulk actions * Status changes * Activity history * Comments * Communication * Attachments * Documents * Settings * Permissions * Automations * Notifications * Onboarding * Empty states * Loading states * Error states * Mobile and responsive states where required You should think through the complete experience. A feature is not finished because the dashboard looks good. # Specific Areas ## Vendor Portal and Vendor Management Potential functionality includes: * Vendor directory * Vendor profiles * Vendor onboarding * Invitations * Qualification * Credentials * Documents * Insurance * Certifications * RFPs * RFQs * Requests * Bidding * Proposals * Contracts * Assignments * Work orders * Deliverables * Communication * Financial information * Invoicing * Payments * Performance * Ratings * Compliance * Vendor status * Vendor discovery * Maps * Vendor portal * Internal vendor management experience The external vendor experience and the internal organization's experience may be different. You should help us determine the appropriate UX and how these experiences interact. The goal is not simply to copy existing vendor-management software. We want to understand what current systems do well, what frustrates users, and where we can create a considerably better experience. # Resources Management Resources can represent things businesses use to deliver services or operate their organization. Examples could include: * Rooms * Treatment rooms * Equipment * Vehicles * Chairs * Studios * Courts * Beds * Machines * Devices * Workstations * Venues * Shared spaces * Other bookable or assignable resources The system may need to support: * Resource profiles * Categories * Locations * Availability * Scheduling * Assignment * Capacity * Maintenance * Status * Restrictions * Conflicts * Utilization * Check-in * Check-out * Dependencies * Related inventory * Rental eligibility We expect you to research how leading systems solve these problems and recommend the best architecture. Resources may connect with other areas of the platform, including scheduling, rentals, offerings, staff, locations, maintenance, and operational workflows. The designer needs to understand these relationships instead of treating Resources as an isolated database. # Rentals Rentals may involve physical items, equipment, vehicles, spaces, or other rentable assets. Potential workflows include: * Rental catalog * Availability * Search * Reservation * Start and end dates * Pickup * Delivery * Check-out * Check-in * Deposits * Fees * Extensions * Damage * Inspection * Late returns * Availability conflicts * Maintenance * Rental agreements * Customer history * Staff workflows * Rental status tracking We want the rental system designed as an operational workflow, not simply a booking form. For example, reserving an item is only one part of the lifecycle. The complete experience may involve: Discovery → reservation → payment → preparation → pickup → active rental → extension → return → inspection → damage assessment → deposit resolution → completion. The UX should make that lifecycle easy to understand for both staff and customers. # Rental Offering Portal The customer-facing experience may include: * Discover rentals * Search * Filters * Availability * Pricing * Rental terms * Add-ons * Deposits * Checkout * Agreements * Pickup instructions * Delivery * Current rentals * Extend rental * Return rental * Report an issue * Rental history You should investigate companies that do this extremely well and identify patterns we can improve upon. The customer-facing experience should be substantially simpler than the internal operational system while still exposing the information customers need. # Affiliate Portal and Affiliate Management Potential functionality includes: * Affiliate onboarding * Affiliate profile * Referral links * Referral codes * Campaigns * Offers * Products and services promoted * Clicks * Leads * Conversions * Attribution * Commissions * Payouts * Pending earnings * Approved earnings * Disputes * Marketing assets * Performance analytics * Referral relationships * Affiliate tiers * Rules * Terms * Notifications There may be separate experiences for: 1. The business managing affiliates 2. The affiliate participating in the program Both need thoughtful UX. The administrator may need sophisticated controls while the affiliate should receive a simple experience that makes it obvious: * What they can promote * How to share it * What activity occurred * What converted * What they earned * What is pending * When they will be paid * What actions they need to take # Work Queue This is not simply a task list. The Work Queue may act as a centralized place for users to see work that requires attention. Examples include: * Approvals * Reviews * Signatures * Requests * Assignments * Follow-ups * Exceptions * Escalations * Cases * Documents needing action * Expiring credentials * Vendor actions * Rental issues * Operational alerts We need help defining: * Queue architecture * Priority * Urgency * Assignment * Responsible party * Status * SLA and deadlines * Filters * Saved views * Team queues * Personal queues * Escalation * Bulk actions * Context panels * Action without leaving the queue This should feel like a serious operational product. Users should be able to quickly answer questions such as: * What requires my attention? * What is most urgent? * What is overdue? * What belongs to my team? * What am I personally responsible for? * What can I resolve immediately? * What am I waiting on? * What has been escalated? * What happens if nobody acts? The designer should research best-in-class queue, inbox, case-management, support, operations, workflow, and approval experiences. # Research Is a Deliverable Research is not optional or something we will completely provide to you. For each substantial module, we expect you to investigate existing platforms. You should be able to tell us: * Which platforms you reviewed * Why you selected them * What they do well * What they do poorly * Which patterns users are already familiar with * Which patterns should not be copied * Where existing platforms create friction * Where there are opportunities for innovation * What you recommend for our product * Why you recommend it Screenshots alone are not research. We expect analysis and conclusions. # Documentation Is Part of the Job Design files alone are not sufficient. We expect documentation explaining: * What the feature is * Who it is for * What problem it solves * User roles * User flows * Business rules * Screen behavior * Interaction behavior * Status definitions * Permissions * Edge cases * Empty states * Error states * Responsive behavior * Developer implementation notes * Important assumptions * Outstanding product questions * Dependencies on other modules * Relevant research findings * Why major design decisions were made A developer should be able to open your documentation and understand how the feature is intended to behave. # Developer Handoffs You must be comfortable presenting your work directly to developers. You should be able to explain: * Why the experience was designed this way * Why a particular interaction pattern was selected * What alternatives were considered * How the workflow behaves * How edge cases work * How permissions affect the interface * What happens when data is missing * What happens when something fails * What states a component can have * How different modules interact * What happens before and after the current screen We do not want a designer who becomes uncomfortable when developers ask detailed questions. You should be prepared to present your work in front of our developers and explain your reasoning. Developers may challenge a workflow or ask why something behaves a certain way. You should be able to explain your decisions clearly while remaining open to better solutions and technical constraints. # Research and Design Presentations For major features, we expect a short research and design presentation covering areas such as: * Competitors reviewed * Relevant screens and workflows * Patterns observed * Problems identified * Opportunities * Recommended mental model * Proposed information architecture * Proposed user flow * Design decisions * What we are doing differently * Risks * Assumptions * Open questions * Recommendations We want to understand your thinking, not just see the final screen. # UI, UX and Research Are Equally Important We do not want someone who is excellent at UI but weak at UX. We also do not want someone who creates extensive UX diagrams but cannot produce a polished interface. We need someone who treats the following as equally important: ## Research Understand what exists and why. ## UX Make complicated workflows understandable. ## UI Create a polished, professional and modern experience. ## Product Thinking Make sure we are solving the correct problem. ## Documentation Make sure the team understands how the product is supposed to work. All of these matter. # AI Use We actively use AI internally and have no problem with designers using AI. In fact, we expect modern designers to understand how AI can accelerate their work. You can use AI for: * Research assistance * Brainstorming * Competitive analysis * Summarizing research * Generating alternative concepts * Documentation assistance * Organizing information * Exploring interface ideas * Creating test data * Accelerating repetitive work But AI cannot substitute for: * Product thinking * Research * UX reasoning * Information architecture * Interaction design * Design judgment * Understanding users * Understanding business rules * Quality control * Original thinking If your workflow is essentially: Prompt AI → generate screens → send screens you are not the designer we are looking for. AI should accelerate a strong designer. It should not replace the designer. You must personally understand and be able to defend every design you submit, regardless of whether AI helped create it. # Do Not Wait for Us to Give You Everything This is important. We will provide: * Product context * Business goals * Existing system information * Developer access * Stakeholder feedback * Known requirements However, we do not want to spoon-feed every solution. Do not repeatedly ask us: Can you show me another platform that does this? Finding those platforms is part of your job. Do not repeatedly ask: Can you tell me exactly how this should work? Determining how it should work is part of the product design process. If we tell you: We need an excellent vendor qualification experience. We expect you to research: * How vendor qualification currently works * What information organizations commonly collect * What vendors are normally required to provide * What workflows exist * What vendors dislike about existing systems * What administrators need * What compliance requirements affect the experience * What patterns are unnecessarily complicated * What can be simplified * How our experience could be better Then bring us recommendations. We want someone who contributes product intelligence, not simply design labor. # Think Beyond Our Initial Requirements We may give you an initial list of requirements. Those requirements are a starting point. During your research, you may discover: * Important functionality we missed * Functionality we do not actually need * Better terminology * Better workflows * Better navigation * Different ways modules should connect * Common industry expectations * Important edge cases * Important user roles * Better interaction patterns We expect you to bring those findings to us. You should respectfully challenge requirements when your research or UX reasoning identifies a better solution. # What Good Work Looks Like We would rather receive: 20 deeply thought-through screens with excellent flows and documentation than: 80 attractive but disconnected screens. A good design should answer: * Who is using this? * Why are they here? * What are they trying to accomplish? * What information do they need? * What actions can they take? * What happens next? * What happens if something goes wrong? * What happens if they do not have permission? * What happens if there are thousands of records? * How does this connect to another part of the platform? * How will a developer know what to build? # Design System Thinking Because these modules are part of one larger platform, we do not want every module to feel like a separate application. You should think about reusable patterns such as: * Navigation * Tables * Filters * Search * Statuses * Drawers * Modals * Detail pages * Activity feeds * Comments * Attachments * Forms * Commands * Queues * Empty states * Confirmation patterns * Notifications * Timelines * Cards * Permissions * Selection patterns * Bulk actions If a good pattern already exists, reuse it. If a new reusable pattern is needed, help define it as part of the design system. # Who We Are Looking For Ideally you have experience designing: * SaaS products * Enterprise software * B2B software * Marketplaces * Operations software * ERP systems * CRM systems * EBMS platforms * Vendor management * Procurement * Workflow systems * Property rental * Equipment rental * Affiliate software * Scheduling systems * Workforce management * Fintech or payment workflows * Data-heavy applications You do not need experience in every category. However, you should have experience designing complex software with interconnected workflows. # Required Skills Strong experience with: * Figma * UX research * Competitive research * Product design * Information architecture * User flows * Wireframing * Interaction design * Design systems * Responsive design * Developer handoffs * Product documentation Bonus experience: * Design tokens * Component libraries * Enterprise permissions * Multi-tenant SaaS * Workflow engines * Marketplace architecture * Complex tables * Data-heavy applications * AI-assisted product design * Prototyping * Usability testing # Collaboration You may work directly with: * Founder and product owner * Product managers * Developers * Designers * QA * Operations stakeholders Expect design reviews where you may be asked: * Why is this here? * What happens next? * Why did you choose this pattern? * What happens if the user does not have permission? * What happens if there are 10,000 records? * What happens on mobile? * What happens if the request is rejected? * What happens if the user leaves halfway through? * What happens when an organization configures this differently? * What happens if this workflow touches another module? * What happens if the user has more than one role? * What happens if something is overdue? You should enjoy answering these kinds of questions. # Deliverables Depending on the assignment, deliverables may include: * Competitive research * Research summary * UX recommendations * Information architecture * Sitemap * User journeys * User flows * Wireframes * High-fidelity designs * Interactive prototypes * Components * Variants * Design system additions * Responsive designs * Empty states * Error states * Loading states * Design specifications * Product documentation * Developer handoff notes * Design presentations # How We Will Evaluate the Designer We will evaluate you on: 1. UX thinking 2. Research ability 3. Quality of UI 4. Ability to simplify complex workflows 5. Product thinking 6. Attention to detail 7. Ability to work independently 8. Ability to document your work 9. Ability to communicate with developers 10. Ability to explain and defend your design decisions 11. Ability to think beyond the immediate screen 12. Ability to challenge requirements constructively 13. Ability to identify missing requirements 14. Ability to understand interconnected systems 15. Ability to use AI intelligently without becoming dependent on it # When Applying Please do not send only a generic introduction. Include the following: ## 1. Your Portfolio Send examples of complex SaaS, marketplace, operational, enterprise, workflow, or data-heavy software you personally designed. ## 2. Your Role For each relevant example, briefly explain what you personally contributed. We want to know what you actually designed versus what the broader team produced. ## 3. Your Process Explain how you would approach designing a complex feature when the requirements are incomplete. ## 4. Research Example Give an example of a project where competitor research, user research, or product research materially changed your design. ## 5. Developer Collaboration Describe how you normally document and present designs to developers. ## 6. AI Tell us specifically how you use AI during product design and where you believe AI should not be trusted. ## 7. One Relevant Case Study Walk us through one difficult workflow you designed: Problem → Research → UX → UI → Tradeoffs → Final Result We are particularly interested in seeing the reasoning between those stages. ## 8. Independent Research Tell us how you determine which products or competitors to research when a client has not given you reference products. Generic copy-and-paste applications will not be prioritized. # Potential Paid Trial For shortlisted designers, we may begin with a small paid design assignment involving one specific workflow. The goal will not simply be to see whether you can make a beautiful screen. We may evaluate: * How you conduct research * Which competitors you identify * What you learn from them * How you define the problem * How you organize the workflow * How you communicate your reasoning * How you handle edge cases * How you document the experience * How you present the design to developers * How polished the final interface is This allows both sides to determine whether the working relationship is a good fit before moving into larger modules. # Potential Long-Term Opportunity This is not necessarily a one-module project. We are building a large software ecosystem with many interconnected business capabilities. For the right designer, this can become an ongoing relationship covering: * Additional modules * New portals * Operational workflows * Design-system development * Feature redesigns * UX architecture * Research * Prototyping * Product documentation * Developer collaboration We are looking for someone capable of helping us design the product, not merely decorate it.