simPRO FormBuilder

Project done with simPRO Software

UI/UX Designer for the Projects Squad:

Team responsible for the larger releases in their star product: simPRO Enterprise

Key Deliverables I produced for this Project:

  • IA / User Flows
  • Wireframes & Prototypes
  • UI Design Solution
  • User Testing
  • Development Documentation
  • Look & Feel Test Cases
  • Duration 10 months (2019)

    Project Overview

    Some screens of the Form Builder project

    Why do we need a Form Builder inside the system?

    The software generated forms for several different purposes across the system (quotes, invoices, purchase orders, they were everywhere). Originally, the system provided templates for these forms - very generic ones - that did the work but didn’t allow much room for adjustments. If the user wanted a specific layout the request needed to go through a customization ticket… long story short, it was a hustle and customers really disliked not having so much control in this area.

    What do users request constantly in the ideas portal? Having the ability to customise their forms easily. Sounded straight forward. But was it?

    For the purpose of explaining this project easily, I’ll simplify some concepts - otherwise it becomes too technical and you might not be able to follow it:
    Template - Document that can be used as a base for other similar documents.
    Form - A template that has already been populated with information/values of a job or a quote.
    Editor - Open source platform integrated with our software that allowed us to modify any template or form.

    Template and Forms
    A template contains tags that can be repopulated depending of the Quotes/Invoices information

    I'll be dropping some comments regarding the process around this area

    We were able to collect the insights of the challenges through the following methods:

    • Ideas portal
      Users submitting requests for specific features
    • Implementation staff
      detecting patterns when assisting users with their implementation
    • Customer support tickets
      Tickets raised requesting help with this section


    Again, we had a fair amount of challenges and restrictions. I’ll list the main ones I can recall.

    We didn’t want to invent the wheel all over again, so part of the product definition included using an existing Document editing tool, the Editor. With a bit of R&D, we were appointed with an open source option that matched the technical requirements our software had. While it made things easier in the developing part, it meant we had restrictions on how we would be handling the forms, how the user flows need to work and the UI itself.

    The template form need to be populated with [tags] that, once rendered, include the value of a specific element. Example: a tag called [TotalExTax] would be rendered as a value figure in a form. That’s how it worked in the existing forms and the company wanted to keep that calculation method for the new implementation as well.

    Even though we would be providing a brand new solution to generate forms, we needed to keep the existing ones functional and accessible so users can transition to this new functionality smoothly and at their own pace.

    We had different hierarchy levels that could interact with this feature, so defining the right editing/read-only user flows was essential.


    As mentioned in the Prebuilds project, the system allows to customise the levels of visibility across the platform depending on the hierarchy levels. A user logged as a business owner will have the highest visibility in comparison to a user logged as a trainee electrician, for example. With this in mind, here are some examples of personas that matched the different needs in the system regarding this functionality.

    Two different Personas that represent a sample of the different type of users that could interact with the Form Builder

    Some projects (the larger ones) would have longer iteration processes to validate that the solution was adequate, while others (the smaller ones) would have a very short iteration one.


    This project started a bit differently, because we received the open source tool we would be integrating with. So as the product team (Product Owner, Business Analyst and myself) started playing with the demo version to understand how it worked, one of the developers from my team examined the code and build a prototype to integrate the tags and values we used in the system with this new Editor. With that functioning prototype we were able to understand a bit better what we could do and what we couldn't.
    We found out we couldn't implement a drag and drop solution at this stage (which was sad, because I had some really cool concepts generated for this solution!). So we started playing with other ways we could integrate the tags in the forms.

    Form Builder process

    The First Loop of Iterations (lo-fi prototypes) included a lot of paper prototypes and wireframes. Brainstorming with product and some of the developers to evaluate if we were conceiving a doable solution. We also had to narrow down the MVP, meaning that this feature would have multiple ongoing releases and we would have to iterate and correct several times to achieve a solution we were all happy with. It was exciting to know that we would have more chances of adding improvements but it was also a HUGE project so that was a bit overwhelming to keep track of it all (we end up having at least 6 large releases, as far as I remember).

    User testing session 1
    One of many task we tracked during usability testing

    The Second Loop of Iterations(hi-fi prototypes) was used to do usability testing with some of the staff, implementation consultants and few clients to validate if we were covering the right user flows and if some of the UI elements we were introducing were straight forward.

    We detected that some of the new UI concepts we added were not very straightforward for some - specifically, when users had to select a template to send a quote/invoice. I made a few different options and iterated a bit until we got a solution that made more sense.

    This iteration allowed us to identify that we were using the term tag across the feature, but that word has already been used somewhere else in the system for other purposes. Using that term again in a different context created confusion, so after detecting that problem we renamed the elements and started using the term ‘fields’ instead.

    Once we had a solution we were happy with, I prepared a handover with the developers in my team and prepared my Look & Feel QA cycle. I also prepared the layout of the new docx templates we would be using for the next releases. We were ready to deploy the first release. Oh, we were nervous. The feedback came pretty quickly, so we should start straight away in the changes we need to implement for the further releases!

    We ran a few long user testing sessions with staff and implementation consultants once we had a full functional build to test it all . Those sessions covered all the user flows. We screen recorded all the sessions which were quite useful to detect some flaws that would need to be solved in the further deployments.

    Which were the major adjustments needed?
    Well, one of the bigger ones was related with the Save option once a user was editing a file. We, the implementation team, knew that the feature autosaved every couple of seconds, so there was no need of having a Save button the user would need to click to get out of the editor mode. There was a small legend that said Autosaved every time it happened, but we identified that the users didn’t notice it! 80% (YES, 80%) of users spent a good couple of MINUTES looking for a Save button once they wanted to finish the editing step to keep moving with the rest of the tasks.

    User testing session 1
    Changes done in the button. The blue buttons were reserved for 'Continuing' actions, while Green were reserved for 'Finishing' actions. We changed colour and legend to avoid confusion.
    quote icon
    This interface looks so much like Microsoft Word that I would expect the Save option would be in this menu ... but it’s not there!
    quote icon

    This session was a big eye opener, that allowed us to understand that the finishing action in this screen was a bit confusing and needed urgent rework.

    Another element we identified as that inserting the fields in the form was not as self explanatory as we thought. Not everyone understood clearly that they needed to select a field to insert it, so we also had some rework to do in that section. This bit actually had to be reworked during several releases until we got something that seemed alright.


    It is a huge project, so I’ll try to explain it in lay language because otherwise it’s going to be a very boring section of this portfolio.

    In the Setup section you can create your templates. In this section you can create, edit, leave them as drafts or make them available for the rest of the system (mobile apps included). If you want to use a template in a quote, you could access them, open them to view that the form was populated with the right information, edit it again, etc.

    eForms Prototype
    Screenshot of the Manage Template section, inside Setup

    In the Manage templates section users could view which templates were already enabled across the system, for which purposes, when was the last day it was used aside other bits and pieces that made this feature a very powerful one.

    Inside the Editor, users could personalise their quotes as much as they wanted. We were shown a couple of documents created by our customers that looked super slicked! They really embraced this feature and went crazy with it - in a good way.

    User testing session 1
    Detail of one of the UI interactions inside the template selection

    Here users had the option of using any template to create a new quote (or any other type of document), modifying them, saving them and keeping track if they had already been printed or sent to the clients. I also added a functionality that detected whether a form was outdated, so users can notice it fast and take actions quickly.

    User testing session 1
    Screenshot of an implemented screen, once users could select either a new template to work with or a saved form (previously prepopulated document)

    As much as I would love to share a very detailed prototype of the solution, I don't want to get in trouble for showing too much because #copyrights. Instead, I'll leave here the link to their help guide, which includes a video with a walkthrough around the feature:
    Form Builder setup - Help guide
    How to use a template inside a Quote/Invoice - Help guide

    Feedback usually was collected either by the implementation team, clients and staff in general.

    Feedback & Improvements

    Inside the Editor: Comparison between first release vs. further iterations. These design desitions were informed by feedback collected from users
    The good things

    Users were so happy that finally they were able to personalise all their documents. We provided them with system templates that they immediately went and personalised. They tested the limits of what was doable in the Editor, which was extremely satisfying. We saw some examples of documents the users generated with the editor and they were quite remarkable. I honestly wasn’t expecting that they would get it so quickly, so it was a very nice surprise.

    The 'not so'good things

    While editing the system templates we provided seemed alright, creating new ones from scratch was a bit of a mission. A user that wanted to create a new template from a blank canvas required a bit of understanding of programming concepts like loops and if statements. If they didn’t, the chances of generating a very wrong and incorrect document were quite high. I wasn’t completely happy that achieving this specific goal became too technical. I think in order to make it a full success, users should be able to figure it out -in most of the feature- without relying on the help guide to do it.

    simPRO Software logo
    simPRO Software

    Private sector

    simPRO Software is a SaaS solution, designed specifically for traddies (or at least, that’s how it started. It has now diversified). This system allows you to create leads, jobs, quotes and invoices, manage stock, assign specific jobs to employees, assign jobs to contractors, schedule asset maintenance, a bit of everything really.

    All copyrights of the solutions belong to simPRO Software.


    Favourite Work

    Check out my other projects too