• Athenahealth's UX team started in 2008, with one person, now 22 and still hiring
• 34,000 providers using Athena software
• Practices vary from 2-2,000 providers
• Web-based, all users need is laptop & internet
• In 2011, providers now using mobile phones, just like the rest of us - 75% of docs had an Apple mobile device
• In 2010, 60% of Athena docs had iPhones
• Built hifi prototype to show value of a mobile EHR
• Web-based app with close-to-native feel
• Use AJAX-driving nav for smoother transitions
• Give users an "add to home screen" reminder for better experience
• Subtle animations for to communicate progress (panel slides, button states)
• Give a logical path: inbox -> patient case -> view request -> make order -> close (back to inbox)
• Support appropriate gestures (don't overdo it); limited gesture use makes web-based testing easier, but hacks can be disappointing (like zoom buttons versus pinch/spread gestures)
• Bigger targets for fingers (44px)
• Rely on standard mobile controls whenever possible
• Simplify workflows for mobile; start very simple and add elements back when users point out difficulties/shortcomings

• Used jQuery Mobile for prototyping

• Showed examples of how web UI transitioned to mobile UI

• Company's user conference was great opportunity to test and get feedback: 3 days, 39 participants, 10 hours of recording

• Discovered an iPhone rig called "Mr. Tappy" for recording mobile tests
• For $2.50 got strips of acrylic, used heat gun to bend it, clipped a webcam to the end: DIY rig
• Most important tasks for docs: view patient chart, view schedule
• Logitech software for controlling webcam: Fixed focus on content (not fingers), flipped the screen to right orientation
• When users tested, they wanted to help make it happen.
• Docs appreciated data density, could a get quick overview
• Offered suggestions for tasks to do on the mobile device (read only doesn't go far enough... when they saw the list of meds, they wanted to refill, prescribe new, right there)
• Quick access to patient overview lets them put requests into context -- when to help remotely, when to bring them in for visit

• Docs offered this feedback even without their real data

• Don't build on mobile every feature from the EHR

• What are the quick things they'd want to do on the golf course, at soccer practice, while commuting?

• Would not replace the desktop EHR, would not replace need for communication with staff - but all of that is okay

• In one year, performed six usability studies over four release cycles

• Getting the team to see user sessions helps build consensus on priorities: what to fix, how to fix
• Confusing logout icon became whatever the user wanted to do with it (open chart, forward, move); moved it to bottom, gave it a proper text label
• Layered on visual cues as feedback came in, increased the fidelity in each iteration
• Surfaced urgent tasks to the top, even though technically redundant, because it's a critical special case
• Important to use real amounts of data (e.g. buttons at bottom of lists will get pushed down when list is long)
• When looking at schedule, the empty slots are just as important for the doc to know as the appointments
• Show doctor a readable summary/confirmation of their new prescription after having entered it in a structured way
• In a 2011 snow emergency, docs could reach out to their patients (and other doctors) even though power was out and roads were impassable.
• Already seeing positive impact after soft launch three weeks ago

CommunicateHealth

• Health education firm, improve health literacy on the web, through best practices and research strategies
• Served as lead writers and editors for HHS's Health Literacy Online guide. Took a lot of existing general-purpose best practices and research, infused with over 700 user interviews. See guide for more details than today's talk can provide.

Why worry about literacy?

• Half of Americans have limited literacy skills: reading, comprehending information.
• Health literacy even more of a problem: 9 in 10 have limited health literacy skills.
• Not only in reading, but being able to use info they're reading to improve their health, for behavior change.
• Stress and sickness can make even cause difficulties for the literate 10%

• (Technique: black out complex words to see what a low-literacy user would experience.)

• Users with limited literacy skills are willing to use the web, and able to accomplish tasks when apps are designed well

• All users benefit from improved readability. Time-on-task improves for all user groups when improvements are made, especially high-literacy users (!!)

Writing for action

• Passive is "about asthma," active is "prevent asthma attacks at home"
• Focus on the reader's behavior, and give them a useful instruction... "what's the action I can take right away?"
• Facts, demographics, "background information" might be interesting, but it's not actionable.
• In asthma example, talk about common causes of attacks that could be eliminated.
• Also make it personable - talk about "your family", making changes in "your home"; resonates with people

Organize content

• Labels are important for helping readers find content: use labels your users know
• Use open card sorting so users can suggest the terms they'd use for content labels
• Not "indoor air quality," but maybe "healthy air"

Reader-friendly web fonts

• Until very recently, number of fonts to choose were limited (and many of the limited options were bad for reading)
• Web fonts can be used widely now (cf Google Web Fonts), but how to choose the most readable?
• Ask: who is audience? what reading problems or disabilities?
• Choose something appropriate for your most challenged users, and it should scale to all others.
• Default to sans-serif (though with proper treatment, serifs can work)
• Use fonts with equal stroke width
• Use medium letter width
• Use fonts with open counter space (e.g. an "open" e, rather than a closed "e" as in Helvetica)
• Use fonts with tall x-heights ("X" is closer to top of other letters)
• Once you find a typeface with all these qualities, it's helpful to find a font with multiple weights (e.g. Open Sans has light, medium, book, bold, heavy.)

Using fonts in context

• Test your fonts with real content
• Users with limited skills will skip over content with dense walls of text, long sentences, long words, and paragraphs with more than three lines.
• Sometimes you can take preexisting content and use type treatment alone to improve readability.
• Keep body text from 16-20 pixels. But different fonts might have different qualities at same pixel-height.
• Keep line length narrow, 9-12 words max (e.g. newspaper columns)
• Use line height of 120-150% (some breathing room between lines)

Create Visual Hierarchy

• Properly styling headings and paragraphs, providing enough whitespace, all contributes to readability and overall feeling of comfort while reading
• Add "at a glance" info at the top, so busy people don't need to read paragraphs and paragraphs at the outset

Resources

• Center for Plain Language
• Accessible Design Guidelines

Slides

• Started with a great example of how hard it is for some people to decode text and avoid distractions.
• Move beyond "don't make me thing," to "don't make me work harder than I already have to"
• Eye tracking between fluent readers and those who struggle (e.g. dyslexic) show dramatic difference - far more, and longer, pauses on syllables; more regression to previous words/lines
• "getting 10 minutes more to take a test" doesn't approach the amount of extra effort required

(Jon spaces out for a few minutes - sends an e-mail...)

SUPPORT ATTENTION RECOVERY

• let users recognize what they need to do, rather than recall it
• for example, show the password rules on login form
• BagCheck login lets you look up your name to see what third-party service you used for login (on social site, it's okay to see lists of user names, and is very helpful)
• Stop using dismissible error messages, show the error messages in context. Otherwise, hard to remember all the errors when you go back to fix.

PROVIDE HINTS INLINE

• vocabulary tooltips, further explanation

GUESS WHEN POSSIBLE

• some struggling users don't like to read, so they try to guess without reading
• following patterns is huge help

FAQs AS EARLY FALLBACK

• some users go straight to FAQ, since they expect questions to have been asked, or to find a phone number there easily

STOP CAPTCHA MADNESS

• things that make understanding hard for machines (visual distortion, background noise) make it especially hard for struggling users to decipher
• strugglers spend lots of extra times looking around the page for clues - don't put in unnecessary stuff that would be distracting

SEARCH WITH AUTOSUGGEST

• help people spell
• help people narrow down search automatically
• use search logs to identify good choices for "best bets"
• show spelling alternatives for frequent spelling mistakes

USE PLAIN LANGUAGE

• use simple words, active voice, reduce use of prepositional phrases
• see plainlanguage.gov (not "accordingly", rather "so")
• active voice is much easier to parse than passive voice!
• prepositional phrase: "the tool that is most efficient", simplified: "the most efficient tool"
• avoid ALL CAPS - when you're decoding words, you get a lot of info from the ascenders and descenders

Forget about UX tools, think about team value: What does team need most to be successful now?

FREQUENT REVISIONS

• "I can create wireframes faster than your guys can code."
• In 2-3 days, we could get the wireframes done, an`d have a review.
• In a week, we had gone through more revisions than the developers could do with code in two months.
• Then UX was swamped with new work ;)

AUDIENCE UNCERTAINTY

• In one of his markets, French government started regulating.
• Now people have to submit a picture of a government document (e.g. social security card) to sign up.
• Existing customers had to re-sign! If product didn't get sign-up flow right, company would lose all their customers.
• Cultural diferences to privacy, security -- how do you test in US for users in France? Gonna have to go to France, find some of their users there, test with them.
• Can't change the rules, but can test the UI so that it works best within constraints.
• If you can present something as a risk, rather than a benefit, it can be more convincing -- "push the risk."
• Finding the right message to convince the stakeholders, is very important -- that's why he's a better advocate now than before.
• Identifying the risk makes spending the money look insignificant -- justify the value in stakeholder's terms

USER KNOWLEDGE

• Product team didn't know what happened once product had been installed.
• Hard to make decisions in a vacuum.
• Ideally: tell product owner, let's spend next three weeks on the road, watching users. But no way that would happen.
• More practical: Let's spend one day a month talking to a customer.
• It's low-friction... not huge benefit with one meeing, but it gets foot in the door, and after a few months, you've built up a lot of knowledge.
• Plus the monthly schedule meant the knowledge could evolve, wouldn't get stale like lots of interviews all at once.

TAKING THE NEXT STEP

• When you start, there's a bit of expectation that things might change
• But after you've begun, change levels off... need to keep "bumping" for more change
• What's the next improtant need in company that UX can address
• Jeremy's progression: Started with mostly wireframes, prototypes; then identified risk of losing customers, a bump that let them start usability testing, then could move into other areas of the product...

PREPARING YOURSELF

• Inertia may make it tough to make change
• How do you prepare to address barriers? What's their appetite for change? Need to find out directly.
• Ask: why haven't they had UX? how do they expect the org to change? where is UX on the priority list?
• Note: Most hiring managers haven't thought about these question.
• Maybe when push comes to shove, they don't want to make the changes necessary to address UX concerns.
• Sometimes people value UX, but it's low on the priority list.
• Is delivering on time, on budget, new features most important? What's driving the company?

JEREMY'S BIAS

• Very much a collaborator, his personal style.
• Lower friction activities. Simple things he can control, show value quickly.
• Use the trust that builds to push for bigger things.
• "Driving the UX wedge" -- keep hammering to provide more value
• Delivering value to the team, not "doing the best design in the world"
• "What is the next most important problem the business has that UX can help solve?"

QUESTIONS

• "How do I design in the absence of usability tests / user input?"
• Best practices: what works generically, based on research, personal experience, common sense, what's out there on the web.
• Look for key assumptions that you're making: if you're wrong, you're screwed. That's the risk, you can present that to others and challenge them on it. If we're wrong, there's a big impact; here's what I think we'd need to do to learn the right answer.

I have long felt that there ought to be more free and open siddur materials, so in that spirit, I am offering it for download with a Creative Commons Attribution-NonCommercial license.

• Ma'ariv for Yom HaAtzma'ut (PDF, Booklet Page Order)
• Ma'ariv for Yom HaAtzma'ut (DavkaWriter)

The booklet is made for printing on 8.5"×11" paper in landscape orientation to be folded and saddle-stitched. I find that bringing a specimen with me to Staples can be very helpful to explain the right-to-left Hebrew orientation. At this time, the booklet's text is Hebrew with English headings and instructions. In the future, I would like to produce a version with a full English translation. (If you would like to offer your own public domain translation of any part, please be in touch.)

The contents are as follows:

• Psalm 107
• Psalm 97
• Psalm 98
• Three verses excerpted from L'cha Dodi
• The typical Ma'ariv text, minus Baruch Hashem L'Olam before the Amida
• Then, before Sefirat HaOmer...
  • Sh'ma Yisrael
  • Hashem Hu Elokim
  • Mi she'asa nissim from Birkat HaChodesh
  • Numbers chapter 10, verses 9-10
  • A tekiah gedolah, followed by L'shana haba'a birushalayim hab'nuya
  • Y'hi ratzon... shek'sheim shezachinu...
  • Psalm 126
• Sefirat HaOmer
• Aleinu
• Ani Ma'amin
• Kaddish Yatom