Lyceum Health supports specialty care patients by helping them get on treatment and by ensuring that they get the most from therapy along the way. Since Lyceum is a form-based company, and because we were preparing to launch our new platform, we wanted to improve the way that we currently manage questions and forms.

I helped transform our legacy company software into something more user-friendly using our current design system, and which allowed us to fulfill our business requirements in order to launch our new product on time.

Our current form/question management software was about 10 years old, and therefore identified as being outdated and not very user friendly. We also wanted to merge it with the rest of our management software and design system. This redesign was needed as our current solution had not been updated over the years to account for our evolving business needs.

Throughout this project, I constantly met and communicated with stakeholders to ask questions, update them on my progress, and be proactive in asking for feedback so that I could continue iterating on my designs. Before designing, I met with our lead engineer, who was the subject matter expert of the current software. I had lots of questions on the current functionality and parameters to better understand the product. As I started to design, I continued to meet with him and my Product Manager to review my work, get feedback, and discuss upcoming stories in the product roadmap. It was important to keep them in the loop as they would also be primary users of this form management software.

Before starting any designs, there were a lot of discussions with the lead engineer to learn more about how questions are currently being managed, what we wanted to keep or change in the new design, and what the different question parameters meant.

Some clarifying questions that I had:

• Do we plan to reuse questions across forms (in the current design, a new question was created for each form even if it was the same). The answer was yes, we wanted to be able to reuse questions.
• Are all of the fields in the current software needed? Not necessarily. The lead engineer created a table of all of the necessary parameters that we would need and what they meant.
• What is the difference between parameter 1 and parameter 2? There were a lot of questions around clarifying what different parameters meant and their functionality to determine what type of field it would be and where it should go.

I decided to look at some other websites (Google Foms & SurveyMonkey) that manage forms to see what worked well. Some helpful takeaways that I had were:

• Drag & drop - common way to manage the sort order of questions within a form
• Tabs - a good way to organize all of the different parts of adding a question
• Side menu - a common way to manage/add different parts of a form
• Question card - each question was separated in their own cards

One thing that I noticed was that a lot of these form builders didn't have a way to reuse questions across forms, which is what we were trying to do.

There were 22 associated stories written by my product manager for designing this form builder.

Whenever we're adding new features/screens, I try to keep our sitemap up to date. It's a helpful reference for all of the screens that we have across platforms, and especially for the dev team to keep track of their components.

From my competitive research, I noticed that both of these options seemed to work well. The sidebar was a very clean approach, especially if we were able to drag and drop form components onto the page. The floating toolbar took up a lot less space, and it was more obvious where your edits were being made.

After this first attempt, I met with my PM and lead engineer for feedback. We decided to go with the floating toolbar, and these are some of the reasons:

• The drag and drop functionality of the sidebar would have taken more dev time
• We did not have enough functionality to put into a sidebar, and it seemed like an unnecessary use of space for only five items
• The sidebar conflicted a bit with our other sidebar, which we were using for navigation between other pages

We used a similar approach to Google Forms and their floating toolbar. However instead of floating on the right side of the questions, we decided that it would just appear at the bottom of the page, but would always float up to be below where the active card (that was being edited) was. The main reason was to reduce programming.

Takeaways for the next iteration:

• Within a form, questions could be part of different categories or sections - what does it look like when you add a category/section?

To address the takeaways from the previous iteration, I tried to design what it would look like when you add a category or section. We decided to add a wrapper/border around all questions contained in the same category. Sections were basically just blocks of text, so like everything else they had their own card.

The main challenge we were trying to solve for this iteration was that questions themselves could have multiple feedbacks, but so could question options. We already accounted for how question feedback would be shown, but how would we show it for question options?
Some considerations we had were:

• Have it in the more (three dots) menu. At the time we had other content in here, and checking it off would determine if it shows or not.
• This ended up not working because we decided to get rid of this menu. First we took out French because we realized that it shouldn’t apply to just a question card, but the whole form page. If you wanted to view the french, users would likely be reviewing the whole form at once, and it would be more work for the user to toggle on the french for each question rather than doing it once for all.
• We then took out “show next question based on answer” once we learned that each option could have multiple next question options, and we needed a way to add more than one. We decided to use icons instead.
• Should options be moved into their own tab since they were getting more complex? This wasn’t ideal because people may want to be filling it out in context of the question and description.

The first design I presented to the dev team was to be able to add multiple rows of feedback by clicking on an “add” button. You could search for feedback that had been previously added by looking in the dropdown.

Feedback: Devs asked if we could use the same feedback table that we had used on another tab, since they could just use the same component. Although it took up a lot of space, I agreed that this was the best way to go due to our lack of development time and not wanting to overload the user by introducing another way to perform the same functionality.

An example of where we were already using this table component:

Since each option could have one of these tables of varying lengths, I wanted to find a solution that could help reduce how long this page would be. I first suggested having these tables open in modals, but the devs were against this because it was harder to save data.

We compromised by hiding these tables in an accordion, which would be triggered when the user clicks on the icon. That way you could only open one at a time, made the page a lot cleaner, and reduced scrolling on the page. The accordion also worked since this content was optional. We decided to give it a coloured background to differentiate it from the rest of the fields.

During one of my meetings with the Devs, the idea of only being able to add questions from their own question list and then linking them in the form vs creating the questions while you're building the form was brought up. This was a pretty big concept, so I decided to create a pros and cons list.

Questions created from their own question list

• Pros:
• we already have the concept of linking because this is what we do with other screens in our app
• you would only be able to edit questions in one place
• form builder would be less complex
• take less time to complete a form

• Cons
• before creating a form, the user should check the list of questions first to make sure that all the questions they need are there
• user may have to leave the form that they’ve been working on to go and add a question if they forgot

Questions created from within the form builder

• Pros
• can easily add a question in the moment if it’s missing
• adding questions in context of the form
• Cons
• too much complexity on the page
• building a form is going to take forever
• adding a question becomes too easy without first checking if the question already exists…will lead to duplicates, and the whole point is that we want to be able to reuse questions.

We decided the best way to go was to only allow users to add questions from a list of questions, or a “question bank”. It started from 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, we decided that it was easier to develop if it was only managed from one place, and would lead to less duplication.

Adding questions

Adding a form

There was a lot of problem solving, communicating, and iterations that went into this project. Although some of the problems that arose were challenging, the product would not be where it is today if those issues didn't come up. Here are the major ones that I identified:

• The complexity of the software and what it needed to do - each question had a lot of parameters so it was sometimes difficult deciding how to display it to users without looking too overwhelming.
• Big decision made late into the design. It wasn’t ideal to make such a big change/decision on the 4th iteration. If we had more time, it would have been nice to work out a flow at the beginning of the process so that there could be less iteration on the hi-fidelity screens.
• Lack of time and development constraints. We had a short amount of time to make this work as it was needed for the launch of our next product. And due to the lack of time, we were also restricted with what the devs could do.

• Communication is key. Keeping each other in the loop, and not being afraid to ask questions. Devs were very helpful in answering my questions when I was trying to understand the existing software.
• Feedback. Without this, we would not have been able to continue iterating and making improvements.
• Utilize our design system. Luckily, a lot of the UI had already been decided because of the design system we had been building. There were a lot of new components that had to be created which was a lot of work, but it would have taken even longer if we had to decide the font, buttons, colour, etc.
• Do what we need for MVP. Our company management software is still a work in progress, but we had what we needed in order to launch our new software on time. The team recognizes that this wouldn’t have been possible if we didn’t have the new form builder and still had to rely on our legacy software.