Siftery Track

Synced Accounts
Siftery Track is a B2B SaaS tool that helps companies make smarter decisions about their software stack through data imported from various financial accounts. As the remote Product Design Intern, I worked with the Siftery team to redesign a part of the Siftery Track product: the Synced Accounts page.
My Role
User flows, Information Architecture, Sketching , Wireframing, UI, Prototyping
4 weeks

The Challenge

The original Synced Accounts page was relatively simple with two sections: accounts that were already connected on the top and accounts to connect on the bottom. The Siftery Track app has grown to be much more complex with various sync states and error states. The current design did not support these complexities, which has led to an increase in support tickets and churned customers.

High-level Goals

  • Reduce user errors and number of support tickets
  • Provide better guidance on recommended accounts to sync to improve understanding of overall spend
  • Explore ways to organize connectors

My Process

1. Discovery

Understanding the Users

The Siftery Product Team shared their existing user research with me. Primary users are typically leaders within a company—usually with 5+ years of professional experience managing a team—who make monthly or quarterly budgeting decisions.

Many companies have no idea what they’re spending on software and whether or not they’re even using the products the team is paying for. Visibility is extremely important as controlling and managing spend can be a huge cost-saver. Since purchasing in companies is becoming increasingly decentralized, tracking spend has become exponentially more difficult.

Prior to my internship, the team also interviewed and collected feedback about the original Synced Accounts page from existing customers who revealed that they:

Weren't sure which accounts they should connect
Did not know how to resolve out-of-sync errors
Found that data was inaccurate at times

Meet Glen

After getting acquainted with research previously conducted by the Siftery team and the various support documentation, I created the persona to focus the Synced Accounts page around user needs and solutions for current pain points.

Meet Glen, the VP of Finance who wants to make smarter budgeting decisions, especially because he does not get to initially approve teams’ spend.

2. Define

Brainstorming Features

To brainstorm features for the product roadmap, I created How Might We and Point of View Statements.

How might we help Glen find out which accounts to connect to get the most complete data?

  • show recommendations based on transactions
  • group connectors by type (finances, expenses, SSO, apps)

How might we guide users to resolve error sync states?

  • show duplicate error message
  • show and provide guidance on resolving errors: duplicate, out-of-sync, wrong upload

How might we guide Glen to resolve the errors?

  • include sync states for banks/credit cards that take longer to fetch data (in progress)
  • refresh connector

Information Architecture

The IA is organized around the new Synced Account page’s five major features. While I kept the existing major features (or what I consider the essential features on the page), I added minor features that would help the user get the most out of the app. The hierarchy below includes both new and existing major and minor features.

User Flow

The original user flow didn’t account for the multiple non-active sync states and refresh options. In order to refresh data, users would have to entirely resync their account. There also was no differentiation for the only error state “out-of-sync,” which could have been a connector that was still syncing or uploaded incorrectly.

To compensate for these limitations, I constructed a user flow that includes variations for sync states, recommended actions, and a simplified data refresh process.

3. Ideation

To approach the Synced Accounts redesign with a fresh perspective, I explored interactions and organization of connectors while still focusing on the key values: providing better guidance and preventing user errors.

In collaboration with the Product Manager, I explored iterations in columns, hierarchy, and data placement. The strongest explorations maintained the original one-column design because of the space and information it allowed.

4. Prototype

We decided to proceed with usability testing with the strongest set of wireframes, which maintained the original one-column design because of the space and information it allowed. Its connectors are organized by type rather than sync states, with recommended connectors called out.

5. Validate

User Testing

I conducted user testing on my mid-fidelity prototype in InVision to see how users would complete certain tasks once they were given some context. I conducted the tests with individuals similar to my persona and have all used some variation of a budgeting tool that allows them to connect accounts.

Participants were asked to complete:

  • Understand and resolve error messages
  • Add a recommended connector
  • Refresh a connector

Affinity Mapping

After the testing, I organized my findings in an affinity map to identify the positives, the issues, and potential solutions. The affinity map helped me prioritize design revisions based on recurring pain points revealed during testing.


  • easy to identify errors and how to resolve them
  • easy to identify errors and how to resolve them
  • easy to identify recommended connectors
  • fast refresh data feature

Pain points

  • Some of the recommended connectors are below “least recommended” sections
  • Error banners will collect at the top if there are multiple errors
  • Doesn’t make sense to include “least recommended” if it isn’t recommended
  • Hover-state information may also be things user would expect to see in a dashboard


The pain points above were revealed during user testing sessions with this prototype


Users can dismiss error banners

The connectors are grouped Connected vs. Accounts to Connect so that the most important information appears at the top

Only the "Recommended" indicator is shown instead of also showing least recommended.

Meta-data is simplified so that we avoid duplicate information with the dashboard.

6. UI

Siftery’s design kit was a work in progress, so I followed the existing visual design elements as best as I could using the product’s existing colors, typography, and iconography.

7. Engineer Review

My prototype was shared with the rest of the team for some final feedback. The Siftery engineering team’s feedback was helpful in designing something that worked not only for the users, but one that was possible to create on the back-end too. Through their feedback, I learned that:

  • The connected accounts auto-resync on a weekly basis
  • It is not possible to direct the user to exact duplicates
  • Some connected accounts need to show realm_id and org_id

8. Measuring Success

To measure how successful the redesign is, we will measure:

  • Support tickets related to resolving error messages
  • Customer retention
  • Accounts connected based on recommendation

9. Recap


This project was challenging yet rewarding because I was able to work with the Siftery team to create the MVP for one of the major parts of the tool. It was challenging at times because the majority of the team worked remotely in different time zones, but I am thankful for everyone’s efforts to bring me up to speed.

I enjoyed solving the problems that users encountered in the original Synced Accounts page—and observing participants validate my solutions! I learned that recommendations and clearly defined states are instrumental in helping users know what’s going on and what to do about it.

Next steps

The next steps would be to further test and iterate on the design.