Desktop
Product Manager, Lead Engineer
2 months
Form management, Business software
One thing that I noticed was that a lot of these form builders didn't have a way to reuse questions across forms, which was something that we were trying to do.
Functionality #1: A way for users to create questions and fill out all the associated question parameters.
From my competitive analysis of other form builders, using cards per question was a very common design pattern that was being used. It provided hierarchy, was easy to browse, and a clean way to contain all of the actions related to a question in it’s designated card.
As you can see, each question is separated in it's own card. This card state is a preview of how a question would appear when being filled out by a user - they would only see the question, question description, and question options.
For users that are creating a question, there are a lot of other parameters that need to be filled out for functionality, but aren't part of the front-end view of a question. By clicking on the edit icon on the top right of the card, the question would change from it's "preview" state to it's "expanded/edit" state.
Initially, we thought that questions would be created while building a form. However, during one of my meetings with the Devs the idea of only being able to add questions from their own page or "question bank", and then linking them in the form was brought up.
We decided this was the best way to go. A big deciding factor was thinking about how users would edit a question that was linked, especially if it was a part of multiple different forms. If you changed it in one form, would you be changing it in another? At the time, it was also easier to develop if it was only managed from one place, and would lead to less duplication of questions.
Questions within the form now had to be read-only. We also needed a way to "link" these questions by searching through a question bank, and "unlink" them to remove them from the form.
Since there were a lot of question parameters to be filled out, having them all listed vertically would cause lots of scrolling. And since each form had multiple questions, we wanted a better way to organize the content. For this reason, and also to categorize the parameters, we decided to use tabs.
Questions had their own set of parameters, but so did question options (question options are what appears in a dropdown list or radio questions, for example). For each question option we needed to be able to add feedback, but since it wasn’t a mandatory field it didn’t have to be visible all the time. There could also be more than one feedback so we needed a way to add multiple.
We decided to have a feedback table open like an accordion-style, which would be triggered when the user clicks on the feedback icon. That way you could only open one question option’s feedback at a time, which made the page a lot cleaner, and reduced scrolling. The accordion also worked since this content was optional.
Functionality #2: A way for users to build forms by inserting form components (think of new questions, attachments, categories, and sections as building blocks).
I met with my PM and lead engineer for feedback, and we decided to go with the floating toolbar, which always appears below the active component being worked on. This was to ensure users would know where a component was being added.
Here are some of the reasons:
In this example, the floating toolbar containing the image insert and link question button is below the second question card since that was the most recently added question.
If I go and click on the view state of the first question, the toolbar would float beneath it since that question is currently "active" and the toolbar always follows the card you are currently working on.
Categories helped determine how questions were going to be grouped on the form.
We decided to add a wrapper/border around all questions contained in the same category so that users knew which category they were working within.
Feel free to navigate through the prototype below:
Since launch, we've received some feedback from our users and these are some of the things that we've been exploring in our next iterations:
Each question had a lot of parameters to work with, which sometimes made it difficult to decide on how to display to users without looking too overwhelming. I also didn’t know what half of these parameters meant initially, so having touchpoints with the dev team as needed and not being afraid to ask questions really helped me understand what I needed to design. I also valued the teams feedback as it allowed me to keep pushing my designs further and iterating until we had the MVP of a product that we were happy with and that got the job done.
Due to lack of time and development constraints, we had to prioritize which features were needed to create an MVP version of the form builder. Our company management software is still a work in progress, and even as I’m writing this there have been some updates. Luckily, we were prepared and knew what we needed in order to meet our business needs at the time, and already have ideas on what needs to come next.
