+StoryMD Health
Problem statement
StoryMD began building an advanced patient portal called ‘+StoryMD Health’ with the vision of empowering users to add, track, understand, and act on their health data.
The goal of this project was to develop the manual entry feature for ‘+StoryMD Health.’ While we offer various methods for automatically adding data to the platform, such as syncing with hospitals and wearables, it remains essential to have a fallback option when none of these methods are available.
Understanding the problem
We involved developers early in this project because I wanted to get their feedback on development times. They insisted on reusing as many existing components as possible to speed things up, even when I mentioned that this might not work well for users. Their primary focus is launching as quickly as possible, with minimal regard for the user experience.
I quickly mocked up the first version based on developers' suggestions. This version had a ‘+’ button, which opened a modal where users could select a category by clicking on chips at the top and then they can fill out the fields. I had serious concerns about the design: the chips were not obvious, and the categories were confusingly organized. This added friction, making it unlikely that users would manually enter their data.
Advocating for iteration
In a follow-up meeting with the developers, I raised my concerns, explaining that we couldn't launch the feature in its current state - it's not usable. I proposed to redesign it, but the tech lead didn’t think it was worth the additional time. They agreed it needs to be improved, but they preferred to launch the version as is, and make changes later if users complain about it.
I didn’t give up. I knew I had to provide evidence to convince the team. So, I suggested pushing back the launch by a couple of days to allow me to conduct some user testing, and the team agreed. If users could successfully complete the task, we launch it. If not, I would make some easy to implement improvements based on their feedback before releasing.
User research
I tested 4 users on how they add manual entries. I showed them the existing design and asked them to add data in different categories. Every user I tested disliked it; they were either unable to complete the task or did so with confusion. The results confirmed my concerns.
Research findings and solutions
I thought the large '+' button should be clear enough that it's the manual entry button, but I was suprised when users told us that it's not intuitive without a label.
I added onboarding tutorials for first time users about where to add manual entires. Also, it's paired with a label now.
The horizontal scrolling of chips has poor discoverability and increases cognitive load, making navigation difficult. Users found it unclear that more options were hidden off-screen and expressed a preference for a high-level menu that displays all options at once before accessing the input modal.
When users click the 'Add' button, they can see an expandable menu with all categories before going to the input modal. The menu contains seven items, which aligns with users’ cognitive limitations.

Originally, the team thought the categories should be self-explanatory, but there are lots of manual entries they users don't quite understand without the context. For exmaple, It's not intuitive what 'Procedure' or 'Lab Test and Measurement' mean without additional context.
Since the 'Measurement and Lab Test' category was unclear, I conducted card sorting and split it into two categories. I added an onboarding screen with examples from each category and a list of top suggestions under the search dropdown to help users understand the categories.