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 Community Profile
Solutions Workspace
Community
Profile
6 months of design, 2 user testing rounds, 14 interviews, 26 pgs of annotations, 900+ minutes of analyses.
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. Tasked with leading the redesign as one of two designers, my first strategic move was to reimagine the user profile—transforming it from a static card into a dynamic content hub. This foundational work was crucial for driving user engagement and setting the stage for a full community renaissance.
① A designated hub for all documents, Figma files, presentations, links, etc. into where all teams creative have access to.
② A hierarchical structure for the features within a Figma design file, with the pages sections by atoms, molecules, organisms, patterns, pages, and prototypes.
So as the product team works through future sprints, many components would already have a lovely home to live in.
and,
③ A component / content flow chart with a new structure, that designated all the feature priorities on our backlog awaiting for design critiques, development feasibility confirmations, reviewing feedback / suggestions, and revisions.
This step took up around 1/4 of our timeline, but was a necessary push to ensure that obstacles are cleared up before engaging in quick weekly design sprints.
And I wouldn’t have it any other way, so PING ME, let me get all the Slack notifications.
| ① Display of Profile ② Display of Contents Table ③ Collaboration and Version History ④ Content Archiving, Restoration, & Deletion ⑤ Collections ⑥ Drafts & Publication Statuses |
| ③ Collaboration and Version History |
To tackle this pain point, was to design the “best of” layout, that enables users to seamlessly manage collaborators, maintain clear ownership, and receive immediate feedback on their actions. Working within an established design system, the focus is narrowed to assembling the right components and interaction patterns to create a cohesive, intuitive flow that felt both efficient and familiar to users. Of course along the way, with any components or features that do not exist, the subtask is to streamline them through a smaller DIRT (design, iterate, review, test) workflow.
Because most times, an essential smaller component, is a cruicial piece of the larger design ecosystem. My job is to build, update, and uphold those components (atoms, molecules, organisms, or patterns) according to the core design system, so that it doesn’t become an obstacle for future project members.
| For the Version History experience, the process was similar — with the added task of designing appropriate toasts for validation messages, and defining how post-publication labels should appear. Within the larger Solutions Workspace design ecosystem, many components can function as “labels.” One of the challenges lay in identifying the right one without overlapping with existing definitions. |
And the pattern is constantly evolving — it’s about the thoughtful planning, refining details, and ensuring it continues to adapt to new feature requests and shifts in the broader tech landscape. But just because a feature will evolve in the future doesn’t mean it can’t be smoothly integrated now. That’s where careful alignment with the design system come in, it’s for ensuring flexibility without sacrificing consistency.
To address this, a version history list was used to surfaces key metadata for each save point — including publication status, version number, creator, and timestamp. I also included an accessible sub-menu for each version, allowing users to delete, copy a direct link, or restore that version as the current live draft.
| ④ Content Archiving, Restoration, & Deletion |
In the previous version of SW Community, uses around deletion and restoration was a big “wanted” point. And within the old forum, if a post is deleted, it meant a more permanent action because...
Restoration was NOT an option. Once it’s gone, it’s wiped from the servers forever.
Thank goodness that this time around, there were backend servers being restructured and it opened up the path for keeping past versions of posts within the product. It’s still quite limited but it’s a start for sure. Instead of having high frequency controls scattered in different areas of the interface or nonexistent at all, this centralized action menu (a "kebab" menu), consolidates all post management tasks, and balances quick access for common actions with safe, organized access to advanced or destructive functions.
The first part is, users are faced with two similar but distinct entry points for post-creation: starting a new post from scratch, or continuing a draft. This created a confusing mental model and led to two key issues:
① The "Abandoned Draft" : Users who intended to start a fresh post might accidentally open and edit an existing draft, leading to unintended changes and content confusion.
② The "Lost Draft" : Users looking to continue a draft might not find a clear path to do so, or might start a new post instead, creating duplicate content and fragmenting their work.
This can be resolved by designing targeted UI components—tooltips and modals—to guide users down the correct path based on their intent.
For users with existing drafts, the system proactively surfaces these drafts. When a user attempts to start a new post, a modal would intervene if drafts existed, asking them to confirm their choice and present their drafts as alternatives. Tooltips and clear visual indicators are greatly used within the draft management area to educate users on the different states (e.g., "Draft," "Published") and the actions available to them, ensuring they understood the workflow.
It was great that we were able to find a solution to this, until this problem morphed into a high priority core problem.
I ran into a unique obstacle that revolved around ranking certain metadata and pensively selecting how to display it without fanning confusion.
Since expanding and redesigning Collaborations and Version History, it opened up a new world where there can be multiple MAIN collaborators within one post, and any one of those collaborators have editing permissions (as opposed to just viewing in the older SW Community) to create a draft and save a draft.
So it becomes, the WHO and WHAT, being the most important aspect of the metatdata that needs to be shown. If a users goes through post creation, and gets to the step of saving the draft, the draft is saved, and the users is now back in their content home. Perfect.
There is also an option to publish, if let’s say the user is finished with post creation, and wants to publish immediatly. Publish button equals public. Also makes sense.
So what does it mean to have both a draft AND a live version? What does publishing mean then?
How do I let the user know that there is a live published post AND a draft for that same content post? How would that display out to the users if the table can only support one publication label (exhibit a).
It has to be “Draft” displayed. Because whether the post is ① published and live ② have a draft, or ③ has both a live version and draft, if that one tag is to be displayed, Draft makes the most sense in informing the users that no matter which collaborator on the team edited it last, there is a draft present. It’s the first thing the users needs to know when they dive back into work, a day from now, a month from now or a year from now.
The “Published” in this scenario is more of a secondary information. It can be grouped in a way that ALL posts present in the post grid are assumed to be live and published UNLESS it has “this so and so tag.”
Also if it indeed is a user’s first time creating this draft and didn’t publish it, that specific information can appear once in the editing space, for example, as a modal.
As this core problem is resolved with the team’s unanimous consent, the next focused area would be to test the community screens.
Data Visualization, and Validation
Before testing, some research questions were defined:
- Does the new information hierarchy align with user mental models?
- Where do participants expect to find collaborator controls?
- Is bulk deletion discoverable without instruction?
We also documented hypotheses—for instance, predicting that the kebab menu would be intuitive but that archive access might require refinement.
Sessions ran 1–1.5 hours, moderated and structured. Roles were consistent: an interviewer to guide tasks verbally and visually, a notetaker to capture real-time observations, and an observer to absorb behavioral nuance. A dry run ensured everyone was aligned before touching real users.
The goal was straightforward but ambitious: validate whether the new Profiles environment felt intuitive before we committed to build. We asked participants to:
- Navigate to Profiles and orient themselves within the space
- Locate and interpret icons—testing for clarity and affordance
- Select a post and find their way to the editing surface
- Delete individual posts and bulk-select multiple posts for deletion
- Access version history and post details
- Explore the kebab menu to view and manage collaborators
- Interact with filtering tabs to sort content
- Locate and open archived posts
And after each round, the team conducted affinity mapping sessions, clustering observations into themes like: navigation friction, icon clarity, action discoverability, mental model alignment. This helped us move from raw feedback to prioritized action items.
- 88% of participants successfully completed the requested tasks
- Average completion time: 1 minute 43 seconds
- Average errors per participant: 3.9
- Perceived ease of use: 4.4 out of 5 (where 1 = most difficult, 5 = most easy)
The numbers told a promising but incomplete story. Users generally found their way, but the error rate signaled where the experience still demanded too much guesswork. Icon clarity, navigation logic, and the discoverability of certain actions (like bulk deletion and version history) emerged as clear areas for refinement.
- Icon clarity was inconsistent—Some symbols read instantly; others required guesswork. This directly informed refinements to our icon library and tooltip strategy.
- Bulk actions needed greater visual weight—Users expected to delete or archive multiple posts but hesitated when the affordance felt buried.
- The kebab menu was discoverable but its contents surprised users—Collaborator management lived where expected, but additional actions felt like bonuses rather than anticipated tools.
- Filtering tabs tested well, but archive access was less intuitive—Users eventually found archived content, but the path revealed opportunities to refine labeling and placement.
Every finding was weighted by frequency and impact. A low-severity issue (e.g., a single user confused by a label) was noted but didn't block progress. High-severity patterns (e.g., 6 out of 8 users missing bulk actions) triggered immediate design response.
Subsequently—in a bigger picture—that data was copied and then sorted against: priority, and feasibility within timeframe. This gave engineers a clear matrix of which components to prioritize now and which to place in the backlog for future design cycles.
- 100% of participants successfully completed all tasks
- Average completion time: 2 minutes 39 seconds
- Average errors per participant: 0
- Perceived ease of use: 4 out of 5
Increase in completion time was expected—tasks in the second round were more comprehensive, and users moved more deliberately through the space. But the elimination of errors and the sustained ease-of-use score confirmed that our refinements had addressed the right friction points.
- Icon clarity needed another pass—users shouldn't have to guess what an icon represents.
- Information hierarchy was adjusted based on how users actually moved through the space, not how we assumed they would.
- Bulk actions received greater visual weight; hesitation during testing made it clear they were too easy to miss.
- Kebab menu contents were reorganized for predictability, ensuring users could find collaborator controls without hunting.
- Archive labeling was refined to match how users naturally thought about where their old content should live.
And because Profiles and tiptap were tested in tandem, insights from one often informed the other. For example, the navigation friction in Profiles might surface a labeling opportunity in tiptap. Collaborator management behavior in one context, can shaped how we thought about sharing in another.
In the end, the research directly informed 12 design refinements across both profiles and tiptap features (i.e. information hierarchy and component behavior) many of which were validated in Round 2's 0% error rate.
Once user testing wrapped, I had a clear read on where our design instincts held up and where they needed to evolve—backed by evidence, not opinion. After final QA with engineering, I handed off the refined designs and shifted into development support through launch.
Working with another enthisiastic ux researcher—it also opened up my eyes on deeper ways to test products, and mini interactions—and it made this journey all the more meaningful. It also helped me solidify what broader or narrower user testing truly means to the overall design.
- Diana, Senior Visual Designer
“It’s very similiar to what I would do in Solution Central...it covers what I need.”
- Vanessa, Senior Demo Architect, FINS
- Vamsidhar, Lead Product Manager, Data Cloud
“Really easy to manage and...not take much time to make sure your stuff is up to date.“
- Tom, RFP Manager
But don’t worry, there’s so much more content waiting to be discovered!