Zengine 2.0

The Goal:
Launch a new version of our signature grants management product that can scale to government and enterprise implementations, reduce time-to-launch for new clients, and slow down churn.
The Team:
At WizeHive I am the Director of Product Design working alongside five in-house designers and one researcher, as well as various contractors, all of us splitting our time with 5 development teams between US and India.
Summary:
​A complete product overhaul is no small feat. Zengine 2.0 has soft-launched this year, with ambitious EOY targets for new client acquisition. This long journey started 3.5 years ago, when I joined the company and was told to find “low hanging fruit” and “quick wins” to increase retention and win new clients. The story that follows is how I proved to the company that a redo was more than worth the effort and time.
Discovery + Definition:

When I first joined WizeHive, the existing grants management SaaS solution, Zengine, had been on the market for about five years, with its powerful features sometimes obscured by lack of design input.

After organizing and analyzing existing client feedback, I spoke to various clients and participated in calls from sales to implementation and support. I documented the intricacies of the software in a product map and deepened my understanding of the grants management domain. It became clear that, although at the core of our product sat a powerful relational database, Zengine did not meet customer needs because it did not reflect the users’ domain.

​The award cycle lies at the center of grants management. Grant-making organizations create one or more programs to support and often fund individuals and groups aligned with their missions. Applicants are awarded at varying intervals (e.g. annually), and the cohorts of grantees that emerge report back on their progress. Zengine 1.0 had made the configuration of an award cycle incredibly time-consuming and complicated… because it did not understand the concept of an Organization with Programs and Cycles.
Discovery + Definition (continued):

Next, I had to bring in internal teams into the design process.

I hosted an after hours session with a dozen implementation leads to mine their expertise pushing Zengine to its limits. I divided the room into each phase of the award cycle and restated the personas involved throughout. The team listed all jobs-to-be-done for each persona then rated the efficacy and ease of each task within the software. In some cases, there were no workarounds available to meet a need.

Limitations included the ability for applicants to collaborate on forms, the ability for reviewers to track all assignments in one place, and the ability for program admins to easily start a new award cycle.

Another important set of conversations involved engineering leaders. I illustrated some concepts to aid our discussion and answer the fundamental question: Could Zengine 1.0 be re-architected to accommodate the concept of Organizations/Programs/Cycles, or would we had to start from scratch?

​The answer was the latter.
Design System + Principles:

By the time we were ready to start development, I had been able to hire my first UI/UX Designer. One of our first discussions was about how to ensure that the new version of Zengine was developed along with a corresponding design system. I credit him with pointing our that our starting point should be a set of design principles.

We included teammates and leaders from product management and engineering to workshop our design principles, then presented the summarized version to the company.

We named our design system Zentience, and from then on have continued to refine it as we build different areas of the product that require new components, from the Form Builder to the Workflow Builder, from the Participant Network to the Grantee Timeline.

​The design system continues to evolve, and there is much work still to be done, but I am glad that we decided to create one from the start, fixing problems from the get-go that have plagued Zengine 1.0 in regards to accessibility and inclusivity, among other things.
The Road to Market:

The past year our developers have been building all the initial pieces that will enable our clients manage philanthropic programs. The final slideshow below showcases a variety of screens meant to serve the needs of different people involved in the process, from applicants to reviewers, from admins to funders.

As we position our new product in the market, it is essential that there is no "break in the chain" so that philanthropic programs can run efficiently and smoothly and meet their goals for supporting important social causes.