Seller Start set out to redesign the seller's daily "starting point" — replacing a fragmented experience spread across Slack, Salesforce, calendars, and dashboards like SPIFF and QAP with a single unified Home experience.

Sellers were suffering from "information anxiety": critical data was siloed across too many tools, and there was no single sales-focused daily digest pulling together what mattered for that day. Success was defined as a unified narrative — compensation, alerts, calendar, account health, consumption/utilization risk flags, and an AI-powered RFP snippet library — all centralised, with a consistent experience regardless of where the seller started their day.

• Ran an initial FigJam workshop with a collaborator to map seller needs across personas: Major Accounts, Prime AEs, and Specialist AEs.
• Instead of moving straight from FigJam into Figma, took the workshop output into Google AI Studio to build a working prototype directly.
• Used the AI Studio prototype to gather early feedback, sharing an async walkthrough video plus a live link so stakeholders could try the design themselves rather than sit through a live sync.
• Produced a low-fidelity mockup alongside a rapid, vibe-coded prototype to validate direction before committing to full design.

• Anchored the Home experience around a 20% Core (compensation, calendar, alerts) that centres every seller, with an 80% Marketplace of tools curated per segment.
• Designed segment-specific recommendations — e.g. High-Volume/Velocity sellers (SMB & Commercial AE/BDR) need to know who is "hot" right now, while Major Accounts/Prime AEs need deeper account-health and utilization signals.
• Prioritised an account health / utilization tracker to flag attrition risk months ahead of a renewal conversation.
• Proposed an AI-powered RFP Searchable Library to reuse successful proposal answers from past wins instead of starting from scratch.
• Chose AI-native tools (Google AI Studio) over traditional wireframe-first Figma work to compress the cycle from idea to testable prototype.

• Balancing a "one-size-fits-all" dashboard against real differences in cognitive load and workflow across seller segments.
• Moving fast with AI-generated prototypes while still validating direction with the right stakeholders before over-investing in polish.
• Coordinating async across a broad set of stakeholders without a live workshop for every review.

• Delivered a low-fidelity mockup and a working vibe-coded prototype used to gather early stakeholder feedback.
• Validated the segmented "20% Core / 80% Marketplace" direction ahead of full design commitment.
• Demonstrated a faster, AI-native path from workshop to testable prototype, later referenced as part of a broader shift toward AI-native design tools (Gemini/Slackbot for research and synthesis, Claude Code/Design and Figma Make for live prototyping).

• Seller Start UX Project canvas (Mario Picariello) — source brief, personas, and JTBD research.
• AI Studio prototype — shared via async walkthrough video and live link.

Teaming Agreements are contracts sellers enter into whenever they share a multi-region account — think Disney US, Disney Europe, and Disney Japan all under one umbrella deal. This project digitised those agreements, moving them from Quip documents into structured Org62 objects.

Only a small number of high-value Org62 accounts (Disney, Amazon, Google, and similar strategic accounts) have a Teaming Agreement attached — but the policy team was accepting two sources of truth: the formal Teaming Agreement object and a separate Quip document covering the same terms. On top of that, sellers creating new Opportunities had no visibility into whether the account they were working on already had an active Teaming Agreement — a gap that risked deals being structured without accounting for existing multi-region split arrangements.

• Designed the modal flows, Roles & Responsibilities tables, stepped navigation, and "How We Work Together" sections.
• Worked directly with both the engineering team and the business/policy stakeholders to translate contract logic into a usable interface.
• Design tools used: Figma (modal flows, tables, stepped navigation prototypes), Org62/Salesforce Lightning (native object and layout design), Quip (requirements gathering and documentation).

• Added new structured sections directly into the Teaming Agreement object so it could fully replace the Quip document as the single source of truth.
• Designed a visual indicator on the Accounts page to flag when an active Teaming Agreement is already linked to an account being worked on.
• Designed a similar visual indicator and link on the Opportunity creation page, directing sellers to the linked Teaming Agreement field the moment an account with an existing agreement is added.
• Used stepped modal progress indicators to guide users through the agreement creation flow, and worked within technical constraints on table components inside Detail tabs.

• Reconciling two sources of truth (Quip vs. Org62) without disrupting the policy team's existing process.
• Technical constraints around table components in Org62 Detail tabs.
• Nuanced UX decisions, like how to make a stepped modal progress indicator intuitive for a contract-heavy workflow.
• Navigating business logic where edge cases (partial agreements, expired agreements, multi-region splits) mattered as much as visual polish.

• Both business stakeholders and engineering signed off satisfied with the completed work.
• The Teaming Agreement object became the intended single source of truth, replacing the parallel Quip process.

• Teaming Agreement Project (Quip) — original project brief and requirements.
• Teaming Agreement Figma design file.
• Meet Nakeem — Team Member Profile canvas — source summary of this project.

Consumption Plans track Agentforce and Data Cloud usage for Account Executives. This project moved that tracking out of manual Google Sheets and into Org62, giving product owners a single, unified in-account view.

Consumption tracking lived in spreadsheets — disconnected from the account record itself, prone to version drift, and offering no real-time visibility for product owners. The team needed a native Org62 experience that could replace the spreadsheet entirely without losing the flexibility people were used to.

• Empty state dashboard.
• Modal creation flow.
• KPI views.
• Bar chart visualisations.
• Edited / updated states.
• Design tools used: Figma (screen flow, empty states, KPI views, bar chart visualisations), Org62/Salesforce Lightning (native build), tooltips and progressive-disclosure patterns prototyped in Figma before handoff.

• Designed intentional empty states so first-time users weren't dropped into a blank screen with no guidance on what to do next.
• Used progressive disclosure to avoid overwhelming users who were used to a flat spreadsheet with a more structured, staged Org62 flow.
• Paired KPI summary views with bar chart visualisations so product owners could see usage trends at a glance rather than scanning rows of data.
• Applied tooltips throughout the data entry flow to reduce ambiguity during the transition from the old manual process.

The core challenge was behavioural, not visual: helping AEs and product owners let go of a tool they were already comfortable with (however manual) and trust a new system. That meant every empty state, tooltip, and data-entry interaction had to actively build confidence rather than just look polished.

• Shipped to the Consumption Plan team as a live Org62 feature.
• Presented as a case study at Config London 2025.

• Meet Nakeem — Team Member Profile canvas — source summary of this project.

Activity Editor is a tool that lets Solution Engineers log their Google Calendar events as Org62 (Salesforce) activities directly from Slack or the Solutions Workspace web app — bridging the gap between calendar activity and CRM data capture. It sits within the Admin & Insights pillar of Solutions Workspace, and today runs as a hybrid Rails + Angular app connecting Google Calendar to Salesforce.

SEs were spending significant admin time manually re-entering calendar events into Salesforce as logged activities — a classic "swivel-chair" problem. Getting SEs to consistently log activities was less a tooling gap and more a behavioural and adoption challenge: the tool had to feel frictionless enough that people would actually use it, and close enough to their existing workflow (Google Calendar) that the transition felt natural.

• Design iterations and feature development across both surfaces: the Slack app and the Solutions Workspace web experience.
• Design QA against the SLDS design system as engineering built to spec.
• Contributed to the Confirming Activities A/B testing research, evaluating how a confirmation step affected logging accuracy and completion rates.

• Google Calendar colour labels integrated — pulling in SEs' existing GCal event colours so the tool felt like an extension of their calendar, not a separate system.
• Pre-set task types — reducing the number of decisions an SE had to make per event to lower friction at the point of logging.
• Confirming Activities feature — a confirmation UX pattern tested via A/B research before going live.
• Mixpanel analytics tracking — instrumented to understand real usage patterns and adoption over time.

• Balancing consistency across two different surfaces (Slack app vs. web app) while keeping the experience unified.
• Security reviews, analytics tracking requirements, and platform migrations added technical complexity alongside the pure design work.
• Getting the default record type and settings right — a recurring theme in support requests, showing how much default-state design matters for adoption.

• Shipped on both Slack and Solutions Workspace.
• Became a core part of the SE workflow, featured in SE onboarding programmes.
• Later evolved into "Activity Editor 2.0," described internally as "your bridge from GCal to Org62," with an established API surface for Google Calendar reads, Salesforce writes, and bulk activity logging.
• Inspired follow-on ideas from the SE community for an Agentforce-powered version that could recommend activity-to-opportunity links automatically.

• Meet Nakeem — Team Member Profile canvas — original source summary of this project.
• Activity Editor Repository Exploration Summary — technical architecture write-up.
• Activity Editor Data Flow — how calendar + user input becomes a Salesforce Event.