Select Page

Zenput Form Builder

At the core of the Zenput Platform sits its Form Builder. Once prided as the oldest piece of code for the company the builder outgrew its potential and was in need of an overhaul. At inception Zenput simply allowed companies to digitize work by taking what was traditionally a paper form audit and making it digital. This allowed companies to then distribute these audits to all of its teams.

Project Role

Lead Product Designer

  • User Research
  • Visual Design
  • Interaction Design
  • Prototyping

The Problem

Rapid growth and user needs led to the bifurcation of features within the product. The power of the Zenput platform is having the ability to distribute work to all your teams and ensuring consistency and accountability. These tasks are distributed as forms that can have formulas, automated workflows, and role-based configuration. The main issue was that all of these features lived in different places of the product. 

The Solution

We held multiple interviews with key customers, customer success teams, and our sales teams. This allowed us to identify our most important user needs, pain points within the product, and the needs of the business. We then leveraged platforms like google analytics, Heap, and FullStory to gain insight as to how people were using the product. This allowed us to identify key information in redesigning the builder. The result was a more robust yet easier to use builder. We were able to bring all the needed functionality into one place allowing users to optimize their forms, trigger workflows,  distribute work, and set configuration all in one place.

Key Findings

  • Building forms are a long process for people
  • People need the ability to globally require all questions
  • People need the ability to see what each question type is
  • People like to know that questions have secondary process attached to them
  • Formulas are extremely hard to build
  • Formula visibility is extremely hard
  • People didn’t know they could set up triggers
  • Creating work post creation is not intuitive

Build Tab

In our research, we realized that people spent large amounts of times inside of the builder. This lead to the decision to create a more focused view dedicated to getting work done. We removed the navigation providing more screen real estate. We then made the decision to break out different actions into tabs so that users could easily get that information without having to scroll through hundreds of questions. We then laid out our question fields in order of items most often used. We helped users avoid hunting and pecking by assigning icons to each field type that would display inline when moved into the form section. We also provided a required icon on all questions that had the requirement set as well as icons for questions that were part of a score inside of a formula or trigger.

Score Tab

We moved scoring into its own tab allowing users to have an easier time in creating them. What was once a small drop-down got its own section displaying the form itself as long a search to find questions without having to scroll. This allowed us to allow batch actions as well as the ability to move entire sections over. The rest of the screen displayed the question themselves as well as a way to tab through the weight of each question.

Trigger Tab

One of the goals was to move features from ambiguous places into areas that actually made sense. Historically after a form was created you could then go and build a report then assign workflows to that form via the report. This was extremely confusing and nested deep within the product. Because of this we moved workflows into the builder itself and renamed as triggers. This allowed for use to find a way for them to quickly see what triggers were assigned to forms and have the ability to quickly build them resulting in a more streamlined workflow.

Configure Tab

The configuration page simply allows admins to set important criteria to each from created such as edit access and privacy on view.

Distribute Tab

A big issue we had was the bifurcation of how forms were distributed. We moved distribution straight into the builder so that people could easily see exactly who could use that form. As a business, we also wanted to push users into setting up recurring projects. So we created a card straight in the builder that would allow them to create a form right from the builder. Once a project is created you could then see it inline in the Distribute tab.