Role
Product Owner
Lead Product Designer
Duration
Jun 2021 - Jul 2024
Contribution
Product management, product definition, UX research, UI/UX design, user flows, visual design, prototyping, usability testing
ioby, which stood for “in our backyards”, was a crowdfunding platform that gave local community leaders across the US the ability to crowdfund for community-based, public-benefit projects to make their neighborhoods healthier and more sustainable.
ioby’s platform was made of a composite of existing third-party tools that were showing their age, and required a significant amount of maintenance time. The planned sunset of Drupal 7, the content management system that ioby.org was hosted on, forced us to re-evaluate and migrate to a more modern tech stack.
For ioby’s internal teams (program, development, and finance staff), ioby workflows would migrate from existing third party systems (Salesforce) to a more suitable workflow hub designed to 1) support ioby’s human resources who elevate and support civic leaders and 2) reduce the maintenance needs and context-switching caused by third party tool sprawl
Note: To read about my work on ioby's crowdfunding product, click
here.
Six months after I was hired on as a Product Designer, it became clear that the organization needed a product lead. I conducted user research between July 2021 and Dec 2021, presented the product vision to senior management, wrote user stories, worked with two engineers, and co-designed the internal and external products with staff members in 2022, participated in the hiring and onboarding of a new CTO in January 2023, onboarded staff to the new internal product in early 2024 and launched the new crowdfunding platform to the public in July 2024.
This was a multi-year migration project and several external factors made it more complex:
- Legacy technology: Drupal, the content management system ioby was hosted on, was sunsetting, which forced an urgency on the organization. The existing tech stack was also complex, which meant migrating to a new tech stack required a deep understanding of both the old and new systems.
- Staff changes: The team experienced significant turnover, including the departure of a senior engineer, followed by the hiring and letting go of a CTO, which necessitated a reprioritization period for the Product team.
- Cross-functional coordination: Effective, organization-wide communication was critical, especially for a project of this scale that would impact the organization as a whole. The importance of this project required every team’s input. This also meant juggling multiple stakeholders’ expectations as each team had differing priorities.
I joined ioby with the context that
- ioby never had internal product and engineering staff before the engineering team and myself were hired
- ioby staff were struggling with their workflow for a while because they spent more time troubleshooting ioby’s existing products than serving the users
- The current crowdfunding platform was unsustainable, as made clear by the engineering team, and migrating to a modern tech stack was necessary for ioby to stay up and running in the long-term.
For these reasons, one of the first things I did was conduct one-on-one interviews with staff members to fully understand their painpoints.
What was made clear was that ioby’s data were dispersed across multiple third-party platforms, all of which were added over ioby’s 15 year existence in response to the Drupal CMS’s limitations. There was no single source of truth. Searching for information and troubleshooting broken integrations between platforms led to manual processes that took significant staff time away from interacting with ioby’s users. This also led to a crucial workflow, disbursing money, to be painstakingly long, forcing the Finance team to troubleshoot and field customer questions on top of their accounting and bookkeeping work.
Drupal 7 couldn't support what ioby needed it to do for crowdfunding functionality, at least not in a way that didn't require a significant amount of time, money and human resources. Users couldn't update their fundraising budget without first emailing staff. They couldn't update donors on their project progress or add multiple team members to a project. Staff also had to manually input information in both Drupal and Salesforce and force a sync between the systems.
ioby was in need of a 0→1 overhaul, not just internally but externally as well. The organization's goal to replatform and redesign the product was not to engage in some feature parity war with an already mature and competitive market of crowdfunding platforms (CFP), but to develop a platform with the best interest of ioby’s users (read: the community leaders, activists, local decision makers) - this was core to ioby's mission!
The vision for this redesign was to:
- Enhance ioby’s functionality and usability for starting neighborhood projects
- Lower the barrier to civic engagement
Even though staff complained about the internal tools, they were user forward in their thinking. Some of our staff were also previously ioby customers, and wanted nothing more than a better crowdfunding platform. From a product perspective, though, the priority was different. The organization needed to first do internal infrastructure work.
Taking inspiration from Aaron Walter’s hierarchy of needs for designing interfaces, I proposed a long-term, phased strategy to move this project forward:
Phase 1 - Pilot an internal feature focused on improving ioby’s data infrastructure, with a focus on ioby strategists’ workflow to support project leaders more effectively than what our current systems allow.
Phase 2 - Continue infrastructure work from Phase 1 to release multiple, user group-specific features on a rolling basis (i.e. match program workflow, partnerships and donor relations workflow, etc.).
Phase 3 - leverage infrastructure work from Phase 2 to enhance external functionality for leaders and donors, foster community connection, and create more opportunities for citizen philanthropy.
Rather than going full steam ahead on the crowdfunding platform, Phase 1 meant consolidating and restructuring the last 10+ years of internal data, creating an internal-focused workflow hub, and exploring the solution of moving away from Salesforce. This was critical to building trust with staff, especially for an organization that 1) never had an in-house product team before I joined and 2) had bad experiences with outsourced agencies who introduced new tech. This approach could show how a product team exists to not only help improve the external users' experience but also for internal staff's.
The technology should be a reflection of the organization – we can’t produce a user-centered, effective and meaningful product if the design of the organization’s systems were siloed and inefficient. The biggest painpoint was that ioby did not have a single source of truth, which required staff to move back and forth between the product (on Drupal) and Salesforce. This was not a good use of anyone's time and resources. Our job as a product team was to introduce a change.
The proposal was to introduce an intermediary state where the crowdfunding Drupal site remained the same, while we funneled data into a new internal tool, with an ideal end state of being completely off Drupal.
We introduced agile development! I created a Product roadmap with epics, rough estimated timelines for each epic in Asana, and presented current and changing priorities once a month in a directors meeting.
With the help of the engineers, I wrote and organized user stories in each epic into sprints. At the beginning of each two-week sprint, we invited everyone to join in a sprint kickoff. The reason we invited everyone was because ioby was small, and we really wanted to make it clear this was an all-hands-on-deck project and to make sure voices from all teams (from fundraising, to customer success, to finance) were heard.
To make more sense of ioby's tool sprawl for myself and for everyone else, I created the below diagram to show how different products worked (or didn’t work) together. Each colored box corresponded to information pertinent to different teams. For example, green represents information that the Finance team worked with. We see that Finance had to move between 8 different products just to disburse funds to users.
Prior to hiring a new CTO and the introducing Retool, I worked with team leads in Finance, Comms, Partnerships and Donor Relations (typically called development and fundraising at other nonprofits), Action and success strategists (typically called Program staff at other nonprofits), and Senior management, to review all the pieces of data relevant to their teams.
Given that the goal is to get rid of Salesforce, I combed through the key Salesforce lists, objects, and fields and asked team leads to rank them by low, medium, and high priority level to give the product team a good sense of what we needed to prioritize porting over to the new system.
Classifying our data assets helped my early design explorations, giving me much clearer ideas on what must be migrated on the backend (for my engineering peers) and in my designs and visual hierarchy for the internal product.
Given how convoluted the workflows and systems were, I diagrammed the state of the workflows as-is, consolidated existing knowledge to further understand the end-to-end of staff workflows, what needed to be developed, and where in the pipeline staff get stuck the most and needs urgent workflow improvement. These diagrams were also helpful selling points to team leads and senior management, showing the complexity and headaches folks are running into.
As seen above, there was a lot of back and forth between workflows and there were parts of the workflows where staff simply improvised.
Having a deep understanding of the product was challenging. Some staff had more historical knowledge and the Product team needed to lean heavily on them to define exactly what actions staff, customers, external partners, and machines take within each stage of ioby’s services. Creating a service blueprint was a multidisciplinary effort between me, the CTO, the Customer Success lead and Marketing lead to envision the most desired end state for the ioby 2.0 MVP.
The goal here was to combine the user research work I did on external users (see here) and map it to backstage actions with staff and tech to have a much clearer vision for data needs and the migration process.
With the onboarding of a new CTO came the introduction of Retool as the software for the internal product (what would essentially replace Salesforce for much of the ioby staff). Our priority was to pilot a workable MVP and get Customer Success staff onboarded to Retool as quickly as possible due to limited time and resources.
Early sketches and iterations showing the internal-facing tool for program staff
Much of the research and discovery was done prior to introducing Retool. Visual hierarchy of information was determined based on what data fields staff ranked as ‘high priority’. Format was determined by what was readily available from Retool's customizable design system.
Having these two ingredients was enough for us to whip up a workable product that closely resembled my design iterations.
Merging my designs with Retool's readily available features
Throughout this design + dev process, we worked with one or two members of the program staff who would be frequent users of the new Retool system so that we could get feedback and iterate for each sprint. This meant that a lot of our sprints revolved around building Salesforce replacement workflows.
Disbursement started when the customer informed ioby that they were ready to cash out their project. Before officially sending the customer the funds, ioby needed to confirm the project information and donations.
One of the main pain points that staff raised was when customers got to this stage (internally referred to as Stage 5), staff had to go back and forth between 7 different systems and over 20 steps to accomplish one disbursement:
- Drupal to check the project leader's budget table
- Salesforce to create a disbursement record
- Freshdesk to communicate with the project leader and pass communication records to the Finance team
- Excel to consolidate finance data
- Metabase, a business intelligence tool, to double and triple check financial numbers between Drupal and Salesforce
- RightSignature to create a disbursement contract
- Bill.com to create bills and disbursement funds to users
To illustrate how convoluted this workflow was, I created user flows showing what tech was used at each step of the disbursement process.
The workflow is split into two parts: 1) Pre-disbursement: checking fiscal status, calculating fees, and communicating needs and expectations with the user, and 2) Disbursement: authorizing accounts, managing the payout, and recording expenses.
Pre-disbursement: Communicating with the user, gathering necessary information and documents
Disbursement: Authorizing payment
Originally, when a user emailed ioby to end their fundraising and ask for their funds to be disbursed, Customer Success had to hand off the email thread to the Finance team and Slack a Finance team member, and change the project's status in Drupal, Salesforce, and Freshdesk. With Retool, we simplified the status change with the click of a button that would automatically update all platforms. We also linked the project's corresponding Freshdesk email thread to the project, so that the Finance team didn't have to manually search for the correct email thread.
Since the Finance team only needed to step in at Stage 5, filtering by stage was an easy way for them to see the list of projects they needed to pay attention to in Retool.
Left: Project in fundraising stage, Right: Project that has requested disbursement
A major painpoint for the Finance team was owning the pre-disbursement workflow and communicating with users, when ideally Customer Success would be the main point of contact to allow for the Finance team to focus on accounting and bookkeeping. This arrangement was essentially a spillover effect of poor internal systems forcing staff to own workflows outside their purview.
Because Retool helped simplify the workflow for Customer Success, it gave room for them to own pre-disbursement communication. To eliminate the need to manually calculate fees then copy and pasting into Drupal, we added an auto-calculating fees table in Retool with radio buttons to choose the appropriate fees percentage, and the option to add to Drupal without the manual copy/paste with a click of a checkbox.
.png)
Left: Fee calculator in Google Sheets, Right: Drupal with fee table copy and pasted
Confirming and updating the project's budget to include ioby's fees
The next step was to communicate with the user about said fees and collect more information. The original workflow required staff to go to Freshdesk and find templated responses that depended on whether:
- The project was sponsored by ioby, another org or 501c3
- The project met their fundraising goal or not
- The project needed to change the estimated project completion date
because the Finance team needed to have the right tax documentation, accurate dollar amounts for bookkeeping, and date for when staff needed to follow up with the customer to ensure the funds raised on ioby were used as intended, respectively.
Rather than having to go to Freshdesk, find the email thread, and copy and paste the right template, we created toggles to change the email with the appropriate information that applied to the project, and a link that opened directly to the corresponding Freshdesk thread in a new window where staff can copy and paste the email text.
Auto-generating an email appropriate to the project's eligibility
Staff then will receive an updated budget table from the user (or simple itemized description) of how the project leader intends to use the disbursed funds. For financial transparency, ioby always posted the updated budget to the project page. Rather than making staff go into Drupal and paste the final budget there, we added this step as part of the Retool workflow as well, simply with an edit button, description box, and save/confirmation button:
Add the finalized budget to both Retool and Drupal
Regardless of whether a project required heavy updating or not before disbursing funds, the important thing was accuracy. This is why we designed the Retool workflow with certain call-to-actions only available once specific conditions were met. One example being the critical last step for Customer Success before handing off to the Finance team. Customer success must click “Confirm Disbursement Information for Finance” as an extra measure to verify data accuracy.
This prevented errors and provided clarity, while building trust among staff, especially staff who already have a lot of distrust with the organization’s data, that everyone was going through intentional checkpoints to ensure accuracy.
Customer Success team's final verification before handing off disbursement to the Finance team
Only after all the necessary information like fiscal status and fees were confirmed did the Finance team step in. From there, they owned anything related to admin, including sending project agreements and collecting 501c3 determination letters where needed. Third party tools like Right Signature and
Bill.com were still used - we weren’t going to build an electronic agreement of AP/AR product from scratch. However, uploading those documents was done within Retool as well. For data consistency's sake, this action automatically updated Salesforce, too.
The "Compare Salesforce Financials" call-to-action also became available, replacing the need for Metabase. Because Salesforce was still in use (primarily for ioby's Partnerships/Fundraising team), the Finance team still needed a way to ensure data matched across platforms and be on the lookout for any red flags re: fraud or donation matching.
This was ioby’s biggest internal update and workflow overhaul since 2012. Much of this case study did not show the workflow around prospecting and engaging with the user given the scale of this redesign. But it was great to see the positive feedback the Product team received from staff members who praised the new internal product's ease of use. Not only did we successfully move all Customer Success staff away from Salesforce and onto Retool, folks were excited and eager to use it, with limited onboarding training from our end since staff was so involved throughout the design and development stage.
Staff posted in Slack channels with messages of appreciation for how quickly they were able to complete the pre-disbursement workflow and relieved over not having to complete what was once a 20-step Salesforce checklist (literally) for every project disbursement. Having Finance focus solely on the administrative side of things helped eliminate excessive context switching on their end.
Buying trust from staff was a big part of this project's takeaway, and it's evidenced through the design alone - many confirmation dialogs were implemented throughout and that intentional friction was not only necessary but welcomed, especially for an organization where fluctuating cash flow was part and parcel of the business.
