Designing a more efficient sales workflow for a B2B merch startup
Scope
Low-fidelity wireframes
Conceptualize & design end-to-end "Projects" feature
User research and user flows
App map development
Tools
Figma, Figjam, Slack, Google Suites
Duration
2 weeks initial design + 2 weeks iteration
Client
Stitchi (B2B merch startup)
Background
The Stitchi cofounders were juggling between email threads, Google Sheets, and Promohunt links in order to keep track of client feedback throughout the sales cycle. Multiply that by 15 active deals, and Stitchi’s two co-founders were spending hours each week just trying to keep their workflow afloat. That inefficiency wasn’t just a nuisance, it was slowing revenue.
Overview
Stitchi is a B2B merchandise startup that helps companies design and order personalized branded apparel for events and internal use. With a lean team managing both product and operations and no budget for additional hires, admin inefficiencies constrained the growth necessary for a young company to survive.
Goal
Conceptualize and design a lightweight internal feature to:
Consolidate Stitchi’s fragmented sales workflow,
Reduce manual work,
Avoid costly labor increases, and
Help close deals faster.
Outcome
I created and delivered all design assets for Projects, a new in-app workspace that streamlines collaboration between Stitchi admins and sales-assisted clients.
Projects also supports self-serve creation and organization so clients who prefer to browse independently can build their own project Folders and request to get in touch when ready, using the same UI patterns and flows.
Problem
How might we use Projects to create a centralized space that helps clients make faster merch decisions while enabling Stitchi to scale sales without growing the team?
Discovery and design research
1.0 Product audit
I reviewed the existing website, customer/sales flows, and external tools used for sales-based communication
Identified friction in IA and current customer journeys
2.0 Workflow mapping
Shadowed Everest’s and Kyle’s daily workflows
Learned that product mockups were created using Promohunt, then reverse-engineered by Everest to appear native to Stitchi. These were emailed to clients as branded “presentation” links. While functional, this was labor-intensive, disconnected from Stitchi’s platform, and prone to communication breakdowns.
Analyzed real email threads and communication methods regarding customer expectations and preferences
Mapped breakdown points across key stages. Stitchi’s sales workflow spans multiple applications, but the real “source of truth” often ended up buried in long email chains. To move an order forward, admins and customers had to bounce between tools and then scroll through threads to find specs, approvals, or the latest link—creating constant context switching, potential for missed updates, and a process that didn’t scale.
Admins also sourced items outside the catalog and frequently replaced default images with client-branded mockups, work that lived in Promohunt, long email threads, or Google Slides.
3.0 Competitive and comparative audit
Studied tools like Figma, Pinterest, Spotify to explore collaborative UX patterns
Benchmarked against Amazon and Custom Ink to understand merch workflows
Identified mental models around browsing, saving, and approving
Understanding the users
Through interviews and shadowing sessions with Stitchi’s co-founders, Kyle and Everest, I documented where the current workflow breaks down and what they need to move faster. I paired those findings with observations from real client interactions to spot recurring goals, constraints, and behaviors across the sales cycle. The following personas summarize those patterns at a glance, describing who each user is, what they’re trying to accomplish, and where friction shows up so we can align scope and design decisions around the people who will actually use the system.
MVP Goals
Co-defined success criteria with Everest to keep scope lean and laser-focused.
Must-have features
Shared Projects folders for each client/campaign
Saved product mockups with image + note context
Lightweight feedback via reactions (heart/star) to reduce email ping-pong
Branded experience inside Stitchi platform
Ability for admins to manually add products not yet in the catalog (with basic metadata)
Attach client-branded mockups to items/folders to support persuasive, decision-ready reviews
Out of scope (for now)
Brand asset libraries: A centralized repository where clients could upload logos, colors, or brand elements to reuse across Projects. Useful for consistency, but deprioritized due to infrastructure overhead.
In-app comments/chat: Real-time messaging between clients and Stitchi admins inside the app. Deemed out of scope due to technical complexity and the decision to route communication through a simpler “get in contact” flow.
Admin-curated collections: Pre-built product collections created by the Stitchi team (e.g. "Best Swag for Tech Events") to help clients start with a ready-made set. A potential future enhancement to support sales enablement, but not essential for the MVP.
My design process
I prioritized fast feedback cycles, clarity, and dev feasibility. We kept it scrappy and lean (i.e. ready when it made sense) rather than spending time on high-fidelity Figma that wouldn’t move the build forward.
Sketched flows for both admin and client views
Iterated on folder UI, feedback mechanisms, and navigation structure
Reviewed early designs weekly with Everest for feedback and tech feasibility
A/B testing
Test #1: modal vs drawer for "Quick view"
Design question: Which quick-view is most intutive in a Folder, a modal or a drawer?
Initial hypothesis:
A drawer might allow quicker skimming while maintaining page context, whereas a modal might feel more immersive but could interrupt the workflow.
What I tested:
Wireframe A Modal: Centered modal with large imagery, details, and clear primary actions.
Wireframe B Drawer: Right-aligned full-height panel showing the same content in one column, image inline; page remains visible underneath an overlay.
This looks like every quick view I’m used to.
I can see the product information better here.
I don’t feel like I’m juggling two panels.
Test #2: "Projects" vs "Presentations" for top-level feature microcopy
Design question: What should we call the top-level workspace, the new feature, where ongoing client work is organized, revised, and reviewed?
What I tested:
Version A "Projects": The feature is named "Projects" to signal a work-in-progress area. Inside a Project, users create "Folders" to organize work by initiative or event (e.g. a Folder like "Staff 2025 Retreat").
Version B "Presentations": The feature is named "Presentations", mirroring the existing Promohunt workflow where admins assemble and send presentation links. The emphasis is on shareable, polished pages.
Choosing "Projects" set the structure (Dashboard → Projects) and the language (e.g. "Folders" or projects that are in progress). On the dashboard, "Projects" gives users a clear home for work-in-progress; inside each Project, Folders group work by initiative. This improved wayfinding and discoverability and sets up the updated *IA diagram below showing where Projects sits in the dashboard and how work flows from the Dashboard into Projects.
*An early dashboard navigation update from Everest changed the IA, so I revised the diagram, conducted the A/B test, and aligned naming and results to the new app map.
Feedback & iterations
Insight #1: Requesting a quote
The program director pointed out a critical user expectation: after saving and reviewing products, clients like her often wanted to get a quote but there was no clear path to do so from within the Projects feature.
This prompted us to brainstorm ways to bridge the gap between saving items and initiating a purchase conversation. A technical constraint was that Stitchi’s system didn’t yet support bulk ordering or unit-level quantity input within folders.
My design response:
I added a contextual “Get in touch” button inside each Folder. Because quantities or checkout aren’t supported—each product is custom-designed by Stitchi—the button starts an in-app handoff to a Stitchi admin and passes the Folder context (favorited items). This keeps the conversation in product and turns a shortlist into a guided next step without email ping-pong, also supporting customers who are unsure about specifics but ready to take action.
This helped transform Projects from a passive organizer into a conversion-friendly interaction space.
Insight #2: Lightweight favoriting before decision-making
In a user interview, a client described a specific workflow or mental model for narrowing down merch options:
There are infinite choices. I want to narrow them down.
I use the heart icon to save everything I like initially.
Later, I review my favorites to compare and eliminate.
The best ones, I move to a folder.
Initially, my design had emphasized organizing products into folders immediately from the product page but this added too much friction for users early in their decision process.
My design response:
I shifted the UX to make favoriting fast and commitment-free, encouraging users to heart products quickly and defer decisions about folder organization. If a user wanted to move a product to a folder immediately, they could do so through the confirmation snackbar.
Reduced decision fatigue in early browsing
Supported real-life workflows based on how users self-sort options
Encouraged continued engagement through low-effort saving
Technical clarification
In my final review with Everest, I also clarified a subtle but important interaction detail: when a product is added to a folder, it's copied, not removed from the general catalog or the user’s favorites. This distinction shaped both the UI language and user expectations.
We updated the label microcopy to “Add to Project” instead of “Move,” ensuring the action felt lightweight, reversible, and non-destructive — especially important for clients evaluating multiple options.
Final solution
After several feedback rounds and weekly check-ins with Everest, I finalized the interaction model and documented the end-to-end user flows for Projects. The flows reflect the chosen IA (Dashboard → Projects → Folders → Items), cover both sales-assisted and self-serve, and honor current constraints (no quantities or bulk checkout; the primary conversion is "Get in touch" from a Folder).
These flows are the blueprint for the UI. The next section translates them into wireframes, starting from the Projects empty state.
In the self-serve path, a customer creates a new Folder, sees a confirmation, then jumps to the catalog to start favoriting products.
There’s also a Favorites view for all liked items and the products are already organized by categories like Tops, Bottoms, and Accessories to make them easy to find.
For self-serve customers, opening a folder, selecting a product, and clicking “Start designing” takes them to the product page to begin a one to one design process with a Stitchi designer. Products are designed one at a time, not in bulk, which reflects the current constraint and Stitchi’s focus on personalized, high quality merchandise.
For Stitchi admins like Everest and Kyle, the sales-assisted flow happens in the client’s account. They create a new folder, add curated catalog picks based on prior feedback, and when needed, use Create custom item to include off-catalog products (name, link, vendor, image). Admins can also attach client-branded mockups to any item so the client sees their logo and colors applied. Clients then review the folder and respond by favoriting or removing items.
Stitchi admins can share a direct folder link by email and clients can also access the same folder by signing into their account. To encourage in-app navigation, any newly created folder shows a small “New” badge that’s visible to each user until they open it. This works well for organizations with multiple users because anyone can create folders and everyone can see what’s new at a glance. Each folder also displays who created it, so clients know the source of the updates.
Clicking Get in touch moves the shortlist into a guided conversation with a Stitchi admin, using the folder context to continue smoothly.
Results
Roadmap commitment
Prioritized for the next build. Dev handoff is complete—with annotated flows and edge cases—so engineering can start without guesswork.
Stakeholder validation
Both cofounders signed off, and the Desai program director (a former Stitchi customer) confirmed that Projects and the new “Get in touch” path close the gap from browsing to purchasing.
Adoption path
Projects becomes the default surface for client presentations—the most visible step in the sales cycle—so adoption will be built in, not optional, across sales-assisted deals. Self-serve creation is supported using the same patterns, so independent clients can start a Project, favorite items, and “Get in touch” when ready.
Expected impact
Less tool-switching and email ping-pong, faster share → approval cycles, and a lower admin load. We’ll track: % of work that stays in Stitchi, time from share → approval, admin time per deal, and client satisfaction.
The Slack message validates the need and suggests Projects will see wide customer adoption once released :)
Reflection
This project reminded me that great UX is usually about removing friction, not adding features. I’m proud that we kept the solution lightweight and focused on the path that matters most.
Working side-by-side with Everest kept the scope honest and the iteration fast. The constraints were guardrails, not handcuffs—they pushed us toward familiar patterns (folders, hearts, a drawer quick view) that made adoption feel natural for first-time users.
Next steps
Final prototype handed off with annotated flows and dev notes
Projects added to Stitchi’s roadmap for near-term build
Will stay lightly involved for QA