Hello there! Welcome to the the form builder application I recently worked on. I can't share names or any specifics about the project but I'll share my thoughts, design, and research process.  

First, let me give you a quick look at some of the whiteboards and explain that a little bit.  I work in an agile software development environment using the 'scrum' framework/methodology. This project has several Product Owner/SME's and based on their requirements I got to work on flowing some initial ideas.
Whiteboards with screen flows and ideas for how agencies will flow through the form builder wizard.
Not worried about look or style just yet, I put together several different flows to accomplish each of the various tasks that were assigned. I'd iterate through those with the Business Analyst and PO until we were all happy.  

While learning and understanding the application building process, I'd come up with several low and high fidelity mockups to help guide the user. Then, I'd move on to a base html/css template such as Bootstrap, Foundation, or Material to ensure the mockups had some familiarity.  While I was working on these screens the QA department would be vetting the various templates out there for accessibility, cost, and various other business requirements.
Screens were designed in Sketch and showcased in Invision with feedback from SME's and Product Owners. 
We first tackled the agency side of the application as this is the most complex part of the process.  We had a requirement for a 'wizard' to help the agencies build their forms cleanly and keep naming convention standards the same across all forms and tenants. We had persona's for agency administrators, with only the basic experience of a word processing application so it had to be intuitive. 

The most complex parts of the form builder is the question builder and the logic controls. Agencies need to be able to build their own questions for constituents. Questions need to be reorganized, made required and have instructions added. Once they have questions built, some logic might need to be added. For example, when a choice is made from a multiple choice question it needs to reveal or hide additional questions for the constituent.

Once an agency has created a form there's a whole new set of considerations. How does the agency publish their form, how does an agency manage forms and users, test draft forms, collect payments, run analytics/metrics, what about custom fields, agency help, accessibility, responsive design. The list goes on. All these sections were again broken down into flows and mockups as we worked through the process. 

As all the items above were considered I made some decisions on the template, started on the design system and style guide for the application.
Design System and Style Guide were both provided in Atlassian Confluence for agency approval.
Next up was the constituent user. How would they interact with the form? It needs to be fast, responsive and easy to use. From our research, mobile users make up approximately 75% of visitors to our public websites so that was my first priority. Mobile first is about designing, developing and marketing for a great mobile experience first and then scaling this up so whatever device the audience is using they always get a great experience and impression.
Some examples of the Constituent form and account administration. I played around with various navigation examples as part of the building process.
Now that we're happy with how the agency builds the form and how the constituent uses the form, its time to test it.  We ran several user feedback sessions and made the necessary text updates and flow tweaks. As with every user feedback session, eyes were opened to missing flow pieces, confusing instructions and unusual questions from users.  Several of the sessions called for tool tips to be added to the form builder and retested with those users.
We used 'usertesting.com' to conduct our feedback sessions and setup our Invision flows.
After some particularly interesting quantitative data was analyzed we started a process of introducing the user to a particularly complex part of the application build.  The idea was to encourage the user to actually read the instructions presented to them.  Many of the user feedback sessions revealed that the users ignored the instructions and started clicking around.
This is an example of one of the ways we tried to encourage the user to read the instructions before attempting to add logic.
While the user feedback sessions were happening, I started working on the help and search screens for the agency.  Security were then brought in for login flows, password requirements, security questions etc. and those screens were also put together.
I designed and coded a complete responsive help system for the application. The help has features like bubbling up popular search terms to the home page and predictive search. 
Finally the form builder itself. The following images are some of the dashboard screens, form management, question and logic builders, as well as a drag and drop form creation process. I've highlighted several of the configuration and preview screens as part of adding form components.
These screens highlight the dashboard, application configuration, question organization, and condition builder.
Here is the form builder screen.  Users can drag and drop form elements into the page and configure them within the builder.
As is with most projects I wanted to include some user feedback. I proceeded to conduct a moderated user testing session over 4 days. The users were representative of the actual user base, the sessions were recorded, I collated my findings and produced a report. As with most user feedback sessions there were lots of eye opening events. A couple I wanted to mention as part of my feedback were.

- Nobody reads anything! - Several of the users didn't read the instructions at the top of each page at all and just tried to guess their way through the application creation.
- Lets get the errors first! - One of the users loaded a form created in the application and rather than figure out what was required on the form they just clicked submit first! This let the user figure out the required items on the page because they all turned red. That way, they just filled out what was "red". That was a new one on me.

I then produced a report with some specific usability/accessibility suggestions, ranked them and even produced some screens in Invision to illustrate the suggestions.

The report was produced using the usability.gov test report template.

The next part of this project that I'm working on currently is introducing new form elements, renewals, document work flow, multi-tenant setup process and a complex fee collection option. If you made it this far, thank you for taking the time to read through my process. I've not shown all of the build screens but I've included what I could.
Here is a quick overview of all the screens, ideas and concepts I've put together so far.