Mobile Recommended Cards
recreate a compex web feature on mobile
StudyBlue helps students, with their value prop being “Less stress, more time, better grades.”
They have 350+ million flashcards in their database, which allows them to do some powerful things. One of the most useful features is called Recommended Cards. As you make a new deck of flashcards to study, the database can actually feed you pre-made cards based on the topic you indicate.
For example – type in “mitosis” and you will see a list of cards, complete with definitions and diagrams, ready to drop into your deck. It is a powerful feature that helps students accumulate study materials quickly.
Unfortunately, that feature only existed on the web platform. As StudyBlue's mobile designer, I was tasked with recreating it in iOS and Android, so that all users could benefit from its power. The physical constraints of mobile devices made it difficult to implement such a powerful feature, so it took a lot of iterating. The final version reflects a thorough process of iterating, testing, and in some cases re-starting. It gives users access to a powerful feature, without getting in their way.
the main challenges
The first challenge had to do with displaying recommendations. As an assistive feature, it could not disorient users, or take them away from their primary purpose. If we covered the entire page with recommendations, obscuring their work, that would be too invasive. Even though it was powerful, it had to feel lightweight. The most elegant solution came from concealing the recommendations beneath the keyboard. Since they wouldn’t be typing at the time they were using a pre-made card, it made sense to swap the keyboard and recommendations.
The next challenge was giving students the affordance to actually use a recommendation. First, I put buttons on the card itself, but they covered the content. After a few experiments, I eventually settled on a button that straddled two segments. I looped engineers in at this point and kept them updated periodically to make sure I was staying sane.
Another major challenge was finding a place from which to trigger the feature. I had recently redesigned the flashcard editor to be clean and efficient, so adding another button anywhere was a big deal. Keeping as much symmetry as possible to avoid the sensation of clutter, I placed the trigger button in the middle of the card as an "i" for information icon. That presented a few problems. What should the button icon really look like? What if a user scrolls the card, will the button disappear? But it was the best solution at that point.
From there I spent time developing the core interactions. How would users navigate the recommendations? Would they be able to swipe to other cards in their deck while the recommendations were showing? What if they wanted to experiment, but then undo their work? Meta-data also needed a treatment. Lots of details needed to be worked out.
Testing and iteration
At this point I created a basic prototype and guerrilla tested with friends and coffee shop studiers. After watching people interact with it, I noticed that most of them tried to drag a card up from the recommendations. Since that was their natural behavior, I restructured the feature around it, eliminating the straddling button. Users could now drag and drop, which seemed to be the most intuitive interaction for them.
Since I no longer had a button straddling the two screen segments, I experimented with treating the recommendations as a skeuomorphic “tray”, partially concealed beneath the keyboard. Users could drag the tray up to see recommendations. That eliminated the need for a trigger button, which was another tentative win. No more obnoxious center button, but would it make the affordance too obscure for people to discover?
At the time, I could find little industry-precedent for a design pattern like that. It was not an easy decision to make. But that choice was later validated, as more apps began using it – like Evernote’s text editor, Apple maps, and Google maps. (This represents one time when I actually jumped the industry. When I realized that, I looked around, did a fist-pump and moved on.) Engineers said that the drag-and-drop interaction was going to be a challenge, but not insurmountable.
I intentionally made the affordance a little chunky, a little bit in the way. Since this pattern was rare at the time, I wanted to make sure it was usable even if the user was drunk and riding a jostling bus. Which, given that we targeted a college demographic, wasn’t out of the question. Later on, once users had gotten used to the pattern, we would reduce the real estate of the down-arrow to show more content.
Executing the project was difficult. I had just redesigned the flashcard editor, which had not yet shipped, and the new interactions depended on it. So it was essentially two projects in one. iOS and Android each tackled half and then taught each other the lessons learned for the second half. The drag-and-drop functionality proved to be the most difficult. There were surprisingly few libraries to support the style we needed.
I helped with QA in terms of visuals and interaction, making sure the design was as accurate as we could reasonably expect given our resources.
We were single-threaded (one engineer each) in both mobile platforms at the time, and had I been smarter, I would have taken our limited resources into account as a design constraint. That being said, both teams were excited for the challenge. They also both expanded later on, and they are currently executing the rest of the project.
I am proud of the project, as I think it represents a big leap forward for StudyBlue’s users, affording them a tool that is not available at that caliber in any other mainstream app (at the time of writing.)