Lessons I learned from a design meeting with Jason Fried.
I recently had an opportunity to talk with arguably one of the best software designers in the web space, Jason Fried. I'm crossing industries here, so for those of you in healthcare (and totally isolated from the tech space) Jason is the co-founder of 37signals, a Chicago-based company focused on building collaborative tools for small businesses. They build some great products. We use Backpack on a daily basis to keep track of our internal discussions. Let's just say if Jason (and 37signals) were focused on healthcare, as an industry we would be much better off than we are now. I've always admired his laser-focus to his product and making the lives of his users better. Needless to say, I have quite a bit to learn from him.
When I first found out I was going to meet with Jason, I figured our meeting was going to be a little Q&A - exchange the typical pleasantries, but Jason would have none of it - he wanted to get to work. So before I knew it I was in the middle of a design session with Jason Fried. This is what I learned.
The original design
- The clinician selects the medication(s) to refill.
- They enter information about the refill request.
- They receive instructions for how to act on the request based on a physician-created protocol.
Below I will give examples which will reference the above designs. See the updated design at the bottom of the post.
Lesson 1) Too much jQuery == You're doing it wrong
Javascript (in particular, jQuery) is an amazing tool for web developers. The technology has made the previously unthinkable possible in a couple lines of code. So what do software designers do? Use it - too much. This causes them to to lose focus and overlook the actual purpose of the application. Instead the designer builds an application to look good, rather than to be usable. Excessive use of jQuery is indicative that your design is getting too complex. Case in point...
Example
I needed a way to collect information about the medications from the user. In order to minimize the screen real-estate, I decided to hide and show input fields based on which medication was selected. To handle this I created medication cards, which when clicked would display the associated inputs for the particular medication. The user would have to cycle through all the medication cards to fill out all the information. I thought it was a clever design...
However, Jason quickly pointed out that this design was likely going to result in major usability problems. No established convention exists for this design; there is no precedent to click each card. Rather, the user would likely click the continue button (which leads to the next page), leading to an incomplete form submit. The other medication cards would go unnoticed.
Jason's thoughts: Most of the "best" applications could be run using technology from 10 years ago.
Lesson 2) Edge cases will show design flaws
Fancy designs are nice, but for them to be functional you have to think about the edge cases. What's going to happen when your user pushes the application to the extreme? Does your design scale gracefully or does it fall apart?
Example
Patients often require multiple medications to be refilled at once. During user testing, we found that medications were commonly refilled in batches of 2 or 3 medications. Thus, we originally designed it to handle (roughly) that number of medications. However, we neglected the extremes of the application.
We were limited to only four medications at once. There was no way to add additional medications to the design without some fancy jQuery animation! This was not a limit of the technology, but of the design.
Also, when refilling one medication the design fell apart. The medication card analogy didn't make sense when only one medication was present.
Jason's thoughts: Get rid of the unnecessary design, keep the application design simple.
Lesson 3) Use English when communicating to your users
Use language to your advantage; it is the common thread that ties all of your users together. Often times as designers we get too caught up in trying to over simplify the content of our application until we get to the point where it no longer makes sense.
Example
After entering the information about the medication, the results of our application are a set of instructions for the clinician to follow. Obviously it's very important that we communicate those instructions as succinctly as possible. Yet, I was using phrases like "Filled by Team" or "Fulfill then Notify", which made sense to me, but to a new user were ambiguous.
Jason's thoughts: If you were in a conversation and you spoke the text would it make sense? No? Then it should not be on your website.
The new, improved design
Based on the suggestions from Jason, I completed a redesign of the three pages. The first page remains relatively unchanged. The second and third were completely revamped.
Following Jason's suggestions I completely eliminated the medication card design and replaced it with a more conventional vertical layout. The vertical layout allows the user to see all of the required input fields without clicking, and eliminates the ambiguity as to what needs to be clicked.
Rather than using ambiguous section headings, I've replaced the entire screen with a set of instructions. These instructions are written out as complete sentences, rather than fragments (or headings).
You can further explore our redesign by checking out our demo. If you like this, please upvote this on Hacker News.
If you want to keep pace with our redesign of Health IT, follow us on Twitter.
