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.
Aug - Sept 2022
Product manager, Lead Engineer
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:
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:
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:
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:
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:
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
Questions created from within the form builder
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 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: