Medpage Today is a health care media company that delivers medical news to physicians and patients. Their primary platform is their website, and they publish their content on a mobile app as well. But for a few years, the design and development of the app hadn't been a top priority. The website had evolved and expanded while the app had fallen a bit behind.
At the very least, the app needed a refresh. But there was a larger question: Why should it even exist when users could just access the mobile website? My task was to examine the reason for having a mobile app and to then propose a new design that addressed that reason.
Before I present my reasoning and design process, allow me to jump forward and show the end result, a prototype of the redesigned app:
The final prototype
Why do news publishers build and maintain apps, if they already have a presence on mobile devices via their websites?
I found some relevant research by Nielsen: “Mobile users who access news through apps spend more time reading the content, but the overall audience for apps is small, so it's essential to know who those users are.”
“News organizations across the spectrum are grappling with this issue, trying to determine a value proposition for developing a native (or brand) app versus focusing on a mobile responsive site. The audience for apps tends to consist of “power,” or loyal, users, but the audience that uses mobile news sites (versus apps) may be quite different. An emerging discussion on the value of apps shows that some publishers believe that discussions around mobile strategy are too app-centric, and they question whether building an app is worth the time and expense. Others are betting that if an app is well designed and the audience is targeted, there could be substantial revenue opportunities.”
There was the answer to my first question: the users of news apps, while fewer in number, are much more engaged than the users of their respective websites.
In terms of revenue, Medpage Today, targeting a professional audience, is even more engagement-centric than a general interest news publication. Focusing on power users makes sense. This leads us to the next question: what do these power users expect from a news app experience?
Its common knowledge that apps can offer a better user experience than websites, but how? To find the best features for our power users, I needed to familiarize myself with the top news apps. After a brief look around, I realized I had to make a distinction between news aggregation apps (Google News, Apple News, Feedly, Flipboard, etc) and apps by news publishers (The New York Times, Washington Post, CNN, BBC, etc). News aggregators gather stories from many different sources, while news publishers produce and display only their own content. Medpage Today is a news publisher. I wanted to stay focused on how Medpage Today compared to other news publishers, and not get distracted by the many bells and whistles of news aggregator apps.
My next step was to take a look at these news publication apps and determine what the prevailing features, functionality, and design patterns were. I compared the most important screens of a news app: the front page (latest headlines), articles, navigation menus, sections, and registration walls.
Features and design patterns I discovered:
• nav panel running along bottom of screen for easier thumb access
• swipable horizontal navigations on front page
• customizable feed for automatic downloading of articles for offline reading
• on section pages, section titles shown in topbar area, replacing brand logo
• ability to add sections to your feed from section pages using + button
• topbars on articles display article UI (save, share), replacing brand logo
• ability to swipe from article to article
• ability to manually save articles for offline reading
• registration walls only after reading articles, not before
Ultimately, not all of these design patterns were applicable to the new app, but being aware of them was informative nonetheless.
To begin the process of constructing a sitemap for the new app, I first created detailed sitemaps of both the old app and the website, in order to fully understand and compare them. I had to be sure I wasn't leaving anything out that should be included in the sitemap for the new app.
The sitemap of the website accounted for all of Medpage Today's editorial content and was well organized, but had a few items that were not applicable to an app.
The sitemap for the old app was missing sections that were featured on the website, was organized less than optimally, and included various things that were either out-of-date or irrelevant to users. However it did contain a few app-specific features which needed to be preserved.
I concluded that the sitemap for the new app should generally mimic the sitemap of the website, with certain website-specific items left out, and certain app-specific items carried over from the old app.
The structure of the final sitemap for the new app is shown below. The items with several children were addressed by utilizing nested subnavigation menus.
The new sitemap was easily translated into a list of screen designs that would be necessary for the new design. For the initial proposal, I wouldn't be designing all of these, but creating this list began to give a sense of scale for the project, and helped define some of the necessary design elements.
The old app had a problem in the user flow. It forced users to log in or register as a first step after downloading the app. Users had to fill out a form and give up their data before they could even see what the app was like.
I revised the user flow so that users can open the app and immediately browse the content and read 5 articles. Even after reading 5 articles, they can keep browsing the landing pages. They just have to register or log in before actually reading any more articles.
Allowing users to try the app before they register should prevent a lot of drop off in engagement. Users will have the opportunity to find out why they should give us their data before they are forced to decide whether they will choose to.
Starting from the list generated from the new sitemap, I selected the most important screens to include in the initial design phase, and created wireframes for them. The sitemap also generated a list of items to show on the main navigation, subnavs, and settings menus.
The goal of this stage was to elevate the look and feel of the app to the level of leading news apps, while maintaining continuity of Medpage Today's branding and simultaneously creating a subtly different look and feel for the app.
• design patterns and features observed from leading news apps
• incorporation of elements from Medpage Today's existing branding
• the revised sitemap, user flow, and wireframes
• explorations in color and typography for unique look and feel for app
I used the app redesign process as an opportunity to explore the boundaries of the identity of the company. Looking through medical industry photography, I found the recurring use of a certain range of blue-greens in medical uniforms and equipment. I used this as a starting point for a unique color palette for the app.
Medpage Today's primary typeface is Minion Pro. This typeface is used in the wordmark, and lends an academic quality to the publication, reinforcing the feeling of quality journalism, trustworthiness, and echoing the look and feel of medical journals. To complement it, I selected Franklin Gothic, one of the classic sans-serifs, with a tradition of being used in the field of journalism, for instance in Time magazine.
The typefaces were used according to function: Minion Pro for content, such as headlines, subheads, and body copy, while Franklin was used for navigation and informational elements.
I chose to design this proposal for the iPhone 6/7/8 screen size, because its smaller screen dimensions pose more of a challenge than larger devices. Adapting the design to work for larger phones and tablets is not problematic when the design works on smaller devices.
I wanted to take advantage of the fact that I was designing a native app and make it feel more luxurious than the mobile version of the website. One of the main strategies for achieving this was to utilize animated transitions.
My aim was to use the dark background of the topbar as a fluid background for not only the topbars of the various pages, but also the intro/loader screen, the navigation menus, and the registration wall. The surface would shrink and expand in a fluid way to accomodate the various states.
I planned all of the possible transitions using a table. All of the screens that a transition could begin on were plotted along one axis, and the screens a transition could end on were plotted along the other axis. Any cell with a dot marked a possible transition.
I plotted 16 transitions that needed to be accounted for. I listed them out and then arranged them in a fluid sequence. Creating this list was the beginning stage of an animated demo of how the topbar and menus could work. What should slide in, and what should fade? In what order? From what direction? And how fast?
I felt more confident about the system I was creating after I had demonstrated the way these elements would interact with one another.
Additionally, there is no way I could communicate these ideas to an app developer without clarifying them to myself first. I created a few diagrams to show how I might share this information with a development team.
Not only the topbar, but the front page, section pages, article pages and videos needed their own logic to govern how they would relate to one another.
The front page was given a unique menu- a horizontally-oriented section menu which the user could swipe within to quickly navigate to other sections without needing to go into the hamburger menu. While within this navigation mode, users can swipe left and right between sections, their order being distated by the order shown on the menu.
Another design pattern I observed from other news apps was the ability to swipe left or right from one article to the next. This is a fairly simple concept, but what would determine what article the user would encounter when they swiped? I took a chronological aproach. The section pages would display the articles in reverse chronological order, and when users were swiping, this order dictate the order of articles that they would encounter. Swiping left would move a user to an older article, while swiping right would move to a newer article.
Showing the user interface in action and bringing together the animated topbar with the transitions between the screens was the next step. To begin this stage, I planned out a demo sequence, noting what interactions would lead the user from screen to screen and when elements would remain static during transitions.
I used Invision Studio to create the interactive, animated prototype. I was happy with the level of realism of the simulation of the flow from page to page. It definitely gave me a precise impression for how the new app would feel when it was finally built.
The final prototype
The research and processes undertaken in this redesign yielded valuable results. I gained insight into the rationale of having an app, brought the content up-to-date with the website, improved the onboarding user flow, removed out-of-date elements from the previous app, and took advantage of the possibilities of enhanced user interface and interactions in native apps.
The most significant change I would make in the process would be to include analysis of metrics from the Medpage Today website and the old app. I would hope to gain insights into any differences in their audiences, determine what was driving their app usage, and find any pain points in the usage of the app.
I would also add an additional stage of planning: a low-fidelity prototype of the wireframes. I moved directly from wireframes to visual design, and didn't have a usable prototype until I was creating the polished, animated version. There were a few mistakes I had to work out in the animated version that would have been a lot simpler to fix had I identified them earlier, and getting a feel for the way the various screens felt in a sequence at the wireframe stage would have made that possible.
This app is slated to go into development next year. Before production begins, there will be a lot of additional design needed for the rest of the screens from the sitemap. Early in the process of fleshing those out, I will begin user testing on variations of the landing pages, registration wall, and article recirculation modules.