I am a UX/UI Designer at Lyceum Health, working on a form-based web platform committed to improving patient care by linking doctors, patients and the pharmaceutical industry.

The company needed a way to digitize healthcare forms in order to improve clinic workflows. I lead the redesign for our company's form management software, enabling us to create digitized forms and/or review, edit or delete an existing form (CRUD).
Platform

Desktop

collaboration

Product Manager, Lead Engineer

duration

2 months

category

Form management, Business software

From paper forms to being stored in our consumer platform, RxNexus.
Forms filled out manually on paper
RxNexus digitized forms
Research
Key takeaways from SME of current software:
  • We plan to reuse questions across different forms
  • We need another way to handle question sort order besides using a dropdown field.
  • An explanation of what form parameters were needed and their functionality.
How do other companies build forms?
Features to explore based on competitive analysis:
  • 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 or floating toolbar - common ways 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 was something that we were trying to do.

Creating questions

Functionality #1: A way for users to create questions and fill out all the associated question parameters.

Decision 1 - Each question will be contained in it's own card

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.

Question card in it's preview state

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.

Question card in it's expanded view

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.

Decision 2 - Create questions separately from the form (like a question bank)

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.

Changes from the previous version

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.

Decision 3 - Using tabs to organize all of the content

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.

Decision 4 - Placement of various question parameters

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.

Considerations
  • More (three dots) menu - but didn’t feel it was necessary to have a menu with just one item in it.
  • Thought about moving options into their own tab in the question card 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.
  • Have feedback fields appear in a modal.
Dev feedback
  • Suggested we use the same feedback table component that we were already using somewhere else.
  • They were against opening the feedback table in a modal because it was harder to save the data.
You can interact with the prototype below!

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.

Adding form components

Functionality #2: A way for users to build forms by inserting form components (think of new questions, attachments, categories, and sections as building blocks).

Decision 1 - Add components with a floating toolbar instead of a drag & drop sidebar

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:

  • The drag and drop functionality of the sidebar would have taken more dev time.
  • We did not have enough functionality to list in a sidebar
  • The sidebar conflicted a bit with our other sidebar on the left, which we were using for navigation between other pages.

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.

Decision 2 - Adding categories

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.

Prototype

Feel free to navigate through the prototype below:

Feedback

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:

Results
To this day, we have been able to digitize 38 medication enrolment forms and we were able to launch our new platform, RxNexus.

As new forms are constantly appearing, or existing forms are being updated, we have an easy way to digitize these questions and collect data from patients and healthcare teams.
Takeaways
Open communication with the team was needed to solve the complexity of the software

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.

Never stop improving

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.

Next
Lyceum - Clinic Dashboard