Our own Dr. Mobile offers a quick primer on how to make mobile experiences usable while meeting your regulatory requirements.
In the July 2012 issue of PM360, we launched the Mobile Rx column and asked for questions from those of you with mobile ills. The response has been excellent, and we received some great questions and feedback. But like all good doctor/patient relationships, this one depends on your input, so keep sending those emails to jgoldman@klickhealth. com, and we’ll keep coming up with helpful prescriptions. One of your first questions gave us enough fodder for a whole column, as it relates to Mobile ISI and how we’re supposed to cram it—and all of our content—onto the tiny screens of mobile devices.
Dear Dr. Mobile,
Thanks for the great first Mobile Rx column. I love the idea of providing mobile optimized versions of our sites, but I don’t know how to do that and keep MLR happy. They’ve indicated that they’re not willing to back mobile if we can’t meet their ISI requirements and I’m not sure how to do that given mobile screen sizes. Please help!
This is the question we hear most often from clients embarking on the mobile journey. What’s a poor marketer to do? Fear not. A number of solutions are quite literally at hand. I’ll assume, for the purpose of answering this particular question that we’re talking about mobile optimization of an existing site rather than a new property. Since this is the first question I’ve handled around mobile optimization, I’m going to step back from the ISI question specifically to provide a little background information on the two broad approaches to consider: a separate m-dot site (e.g. http://m.klickhealth.com) or a so- called “responsive design” that uses the same underlying HTML pages but lays them out differently depending on the screen size and resolution of the device accessing them (e.g. www.klickhealth.com with different layouts of the same content for desktop and mobile).
There are tradeoffs in favor of both approaches, but the key difference is that m-dot and www sites can be completely different, which can be a big benefit. But they also have two complete code bases to worry about updating and maintaining, which can be painful and costly (not to mention the added complexity of keeping both in sync with regulatory compliance issues). A responsive design unifies those code bases into a single set of HTML files that automatically select different styling to match the device, which simplifies maintenance but is more complicated to get through MLR reviews and more restrictive on the difference between the two sites. To get a good understanding of a responsive site, visit www.breakingnews.com, an MSNBC property, from your smartphone, tablet, and laptop to see how it automatically adjusts the layout (or visit it on your laptop and slowly make your browser’s window narrower to see it work in real time).
This is important for the ISI question because it changes the way we handle display. Separate code bases mean we don’t have to try to adapt the desktop approach to mobile. A responsive design means we only have to worry about keeping the safety information updated in one code base for maintenance, but we also have to make sure it’s built with enough flexibility to meet MLR requirements for both screen sizes. Our general rule of thumb is that responsive is a great approach when the content and user needs don’t change much between desktop and mobile, but that m-dot sites are better when there’s a significant difference between the two. We tend to opt for m-dot sites for most of our pharma and biotech clients, since the need states for mobile users tend to be quite different than their desk dwelling colleagues. Think, for example, of the types of information you need on mobile (quick hits, answers to specific questions, definitions, co-pay cards, etc.) compared to desktop (deep research, animations and videos, printed materials, forms and tools, etc.). A responsive design could only display a mobile layout of the same thing you would see on the desktop, whereas an m-dot site can completely change the information architecture of the site, provide radically different navigation, etc.
So, for the purposes of answering our anonymous query (which reminds me: feel free to ask for your name to be withheld if that’s more comfortable), let’s assume we’re taking the m-dot approach. We can cover our approach to determining the mobile site’s information architecture and features in a later column (especially if someone writes in with a question about it—hint, hint), so let’s assume that you’ve done all that and are now just wrestling with Anonymous’ question above.
If our experience in taking mobile optimized designs through MLR at various clients has taught us one thing it’s that there’s no unified approach to presenting ISI that’s going to work for everyone (especially for black box drugs). Let’s take a look at the top three options that seem to meet the broadest range of MLR requirements, ordered from the most compliant to best user experience:
ISI on Launch: Display a full screen of ISI on launch, which visitors need to scroll through before arriving at either a “Confirm and Continue” button (for drugs with a single indication) or a “Choose Condition” button (for drugs with multiple indications). All subsequent pages have a persistent, short footer at the bottom that includes a button for expandable ISI.
Scrollable ISI Footer: Include a box that occupies the bottom 1/3 of every screen that contains ISI and is independent of the body for scrolling (i.e. you can scroll the top 2/3rds of content or you can scroll the bottom 1/3 of ISI). Make the header of the box tappable to expand it to full screen.
ISI Anchor Button in Header: Include a prominent “Important Safety Information” button in the header of every page that is linked to an anchor in the footer of the page. Tapping the button will have the effect of scrolling all the way to the bottom of the page to display the ISI full screen. Although the prominent placement of the button in the header is good for compliance, jumping down to an anchor on the same page can be disorienting (especially since most mobile browsers don’t show a scrollbar when you aren’t scrolling). Don’t forget that you’ll probably need to also include a prominent link to “Prescribing Information” on every page of the site, which will eat a little more of your real estate. We’re fans of including that as a button in the header or top navigation if that meets your MLR requirements.
So that should wrap up your Mobile Rx for ISI display issues. Did that help you out? Did it raise more questions? Let me know.