It’s Skye! I’m a senior product designer
that builds durable design systems
and research-led experiences
for complex products.
Product Desgn & Sys / Solutions Workspace Tiptap Features
Solutions Workspace
TipTap Features
7 tiptap redesigned features, 500+ interaction states documented, 2 design system layers adhered to (SLDS + QDesign), 1 source of truth for annotations & best practices
New York City
Web Product
Solutions Workspace, with over 24k users, had a flagship community forum that catered to Salesforce Solution Engineers, had lost its luster over time.
While the Community’s feature enabled basic post creation, it never evolved into the vibrant hub users expected—and eventually, they began to drift away.
The designs assets created in this project were in tandem with Solutions Workspace’s Community Profile. For this side of the product, I stepped in to lead the discovery and design of new components. That meant auditing existing interaction models, pinpointing friction points, and strategically expanding the feature set—all while leaning into the underlying Salesforce architecture. The mission was simple: transform the “Create Post” from a basic editing tool into a dynamic space where engineers could actually connect, share, and collaborate.
However, for internal products like Communities, we operate within an additional layer: Q Design. Think of Q Design as a thoughtful sheath over SLDS—a complementary system that adapts the foundational language for internal audiences. While SLDS serves external-facing products with broad, public-facing considerations, Q Design is tailored specifically for tools used by Salesforce employees and internal teams. It respects the core patterns of Lightning but introduces opinionated adjustments that account for internal workflows, tighter integration needs, and the nuanced expectations of users who live inside Salesforce every day.
Given this layered foundation, the work was never about reinvention. It was about thoughtful extension within and across both systems. Every component needed to feel native to the ecosystem—honoring both SLDS standards and Q Design nuances—while still pushing the product forward.
My role was to study existing assets from both systems, understand their underlying logic, and then carefully design new patterns that expanded functionality without breaking coherence. This required balancing ambition with discipline: honoring what worked across both layers while introducing principled UX improvements that felt both fresh and familiar. The result was not disruption, but evolution—expanding what was possible within a multilayered system without sacrificing consistency, accessibility, or engineering feasibility.
Design decisions were grounded in foundational UX heuristics:
① Clarity of affordance, feedback visibility
② Predictable state transitions, and
③ Cognitive load reduction.
Even within accelerated timelines, lightweight validation loops were introduced. Rapid prototypes were built and tested internally with cross-functional teammates to compare interaction models and identify which patterns felt most intuitive within the Q Design layer.
These prototypes were also used during user interviews to observe real-time reactions. Rather than debating opinions in a vacuum, the team watched users navigate alternative flows and articulate which experiences aligned with their expectations.
This iterative, behaviorally-informed approach ensured that final design choices were not arbitrary—they were grounded in observed user needs and respectful of the multilayered design infrastructure beneath them.
| ① Accordion ② Carousel ③ Link Button Menu ④ Embed iframe ⑤ Image / Image Text ⑥ Tables ⑦ Carousel |
As a solution, I approach the challenge with a context-aware link menu that surfaces precisely when and where users need it—directly adjacent to their selection. Rather than treating this as a isolated component, I designed it as a system-level addition that needed to account for multiple states (neutral, active, error, success) and flexible configurations (with or without descriptions, small or medium sizing, required or read-only fields). Every decision was made with an eye toward scalability: this component would need to work across contexts, not just within the current feature set.
It is a lightweight, context-aware link menu that surfaces precisely where users need it. Every interaction state was accounted for:
① visual feedback for successful link attachment,
② clear error messaging when something went wrong, and
③ flexible sizing to accommodate different input needs.
Throughout the design process, I kept engineering engaged in ongoing critiques to pressure-test feasibility. These conversations weren't about handing off specs—they were collaborative problem-solving sessions that shaped the final component architecture. The result was a link menu that felt intuitive to users and was technically sound to build.
Users gained transparent control over link attachments, with immediate visual feedback that eliminated guesswork. More importantly, the component was designed to scale—ready to be repurposed across the product without reinvention.
The new link menu gave users transparent control over attaching content. No more guessing whether a link took hold—success and error states provided immediate clarity, and the proximity-based interaction kept the experience feeling effortless and intuitive.
Video embedding for the users, was a black box. Users could drop a link, but had no control over playback behavior—autoplay, muting, looping, or defining start and end times. This lack of control diminished the quality of posts and forced users to accept platform defaults that didn't always serve their intent. And although veteran users had found ways to navigate the friction, newcomers were left to struggle without that institutional knowledge. So the challenge became clear: level the experience so that every SE—whether ten years in or ten days—could engage with confidence from day one.
For videos, I designed a focused, lightweight control panel that surfaces when users embed a video. The challenge was balancing depth of control with cognitive simplicity—giving users powerful options without overwhelming them. I grouped controls intuitively (playback behavior, timing, audio) and ensured every toggle and input field carried clear affordance.
One obstacle emerged early: the visual alignment of labels with their corresponding toggles. After exploring options, the team landed on right alignment—a deliberate choice to counter the negative space and create cleaner visual rhythm. It was a small but intentional decision, a reminder that sometimes design is about trusting what looks right, not overthinking what feels safe. Throughout, the video solution never shifted: give users control, not complexity.
This feature required particularly close engineering partnership. Video playback controls touch platform-level behavior, and not every desired interaction was technically straightforward. Through iterative critiques and feasibility reviews, we landed on an implementation that delivered the control users needed while respecting engineering constraints. The back-and-forth wasn't a hurdle—it was essential to shaping a realistic, shippable solution.
Users finally had granular control over video behavior. Autoplay, muting, looping, and custom timestamps were no longer hidden—they were explicit choices users, themselves, could now make with confidence. The feature transformed video embedding from a passive act into an intentional part of post authorship.
Image handling in the original editing space was functional but rigid. It worked, so it had never been prioritized for improvement. Stepping in to improve this feature, meant evolving the "good enough" standard up to “what it’s meant be”.
In addition, users had minimal control over sizing and no streamlined way to pair images with captions or accompanying text. This constrained visual storytelling and forced users into layouts that didn't match their intent.
Size variations on what images could be like
This feature was the most straightforward of the three—but straightforward doesn't mean unimportant. I defined a flexible yet simple system for image display: clear size variants (small, medium, large) and optional caption treatments that integrated cleanly with the existing content hierarchy. The goal was to refine what was already there, and while at it, give the Solution Engineers slightly more control over how they want the post readers intake their content.
After quick validation loops of confirmed feasibility on the simplicity of the image solution, the team moved on from designing to backend implemetation.
Users now, gained the ability to size images intentionally, or pair them with text in ways that supported their storytelling. The feature proved that giving users control doesn't require elaborate solutions—sometimes the most impactful work is also the most restrained.
The result was not just three new features. It was a renewed post editing experience that put users back in the driver's seat, restored their confidence, and laid the groundwork for future expansion.
| Annotation & Best Practices |
Strong systems work, demands strong documentation. While early exploration involved the usual messiness—whiteboards, sticky notes, personal mapping sessions—the final deliverables were intentionally structured for longevity and cross-system clarity.
Every screen was built with clean hierarchy, labeled components, and clearly defined spacing rules. Margin systems, border radii, color application standards, and state-based behaviors (like hover stroke interactions) were all documented to ensure continuity—with explicit callouts for where Q Design diverged from or extended base SLDS patterns.
If another designer or engineer needed to inherit the work, they could do so without reverse-engineering decisions or guessing which system governed which behavior.
Example: What part of the documentation may look like
But annotation went deeper than the "what." I made a point to capture the "why” as well. Design intent was recorded alongside implementation notes to support engineering collaboration and future iteration.
Where Q Design introduced a specific adjustment, the rationale was documented: internal user behavior patterns, workflow efficiency gains, or technical considerations unique to the internal tooling space. The goal was never just visual polish—it was operational clarity across both design layers. This practice transforms design from a collection of screens into a transferable, scalable product asset that lives comfortably within a complex ecosystem.
Data Visualization, and Validation
- A structured script was written to guide conversations consistently across sessions.
- Backup materials were prepped in advance, anticipating potential technical hiccups.
- Team roles were clearly defined during a full dry run: an interviewer to guide users through tasks verbally and visually, a notetaker to capture real-time observations and manage logistics like recording and link-sharing, and an observer to absorb behavioral nuance without interrupting the flow.
This level of preparation ensured that when users showed up, I would be ready to listen—not scramble.
Some data points that the team considered to capture, was:
① time to compete task
② yes or no to completed task
③ errors or pathway divergence, and,
④ what their rating was for the task based on dificulty.
And yes—sifting through 900 minutes is no small task. But the richness of the data made it worthwhile.
- Card sorting exercises to understand how users expected information to be grouped and prioritized.
- Quote extraction to capture authentic user sentiment and pain points in their own words.
- Behavioral pattern mapping to identify recurring navigation logic and decision-making habits.
- Ranking exercises where users evaluated feature clarity and surfaced what mattered most to them
This wasn't about collecting surface-level feedback. It was about uncovering directional insight—how users thought, where their confidence broke down, and what mental models they brought into the experience.
My role now includes maintaining Q Design system components, bridging new designs with established patterns, and ensuring the system remains coherent as it scales. This work happens in close partnership with my engineering counterpart, who owns the technical side of the components. Together, we keep the system up and running—addressing updates, fielding feedback from product teams, and making thoughtful decisions about when to extend versus when to refine.
This governance model protects system integrity while enabling growth. It ensures that new features, components, and extensions integrate seamlessly into the established ecosystem—preserving coherence without stifling innovation, and honoring the relationship between the foundational SLDS and the internal Q Design layer that sheathes it.
- Vamsi, Lead Product Manager, Data Cloud
“I love the tooltips on the corner of these elements, learning curve type of stuff!”
- Randy, Solution Engineer, Lead
- Tyler, Product Manager
“I’m more comfortable with the selection [in the editing space] now.“
- Tom, RFP Manager
| Oh dang, you’ve hit the end of the story! But don’t worry, there is much more in the longer version just waiting to be heard, so don’t be shy to connect! |