Expensify: A Case Study

I hadn’t heard of Expensify before I saw a TechCrunch piece on the company this afternoon. I happened to have several expense reports outstanding for a consulting client. I hate doing expense reports – scanning all the pieces of paper, putting together a cover document and putting everything into a PDF. Except during the relatively rare interludes in my career where I’ve had an assistant I can thrown receipts at and then race out of the room (Hi Andrew!), I’ve always been really bad at these. I have no excuse: my first boss taught me many useful skills, and precise receipt keeping was one of them. I just hate doing the reports. For that matter, I was never all that good at getting the receipts to my assistants.

Expensify LogoSo after reading the TechCrunch article I logged into Expensify, and half an hour later all my consulting expense reports but one were done and sent off. All of my expense reports for Linked Medical, our new startup, were done too, and filed in the “pay when we have more money” bin. I don’t think any web based tool has ever become so essential to me so quickly. One of the first “ASP model” web applications I ever used was the Ariba purchasing system, after my early-2000s startup became part of a much larger company. It was truly terrible. Fortunately I had an assistant.

Expensify’s product is pretty far from that original Ariba system. Sure, the software isn’t perfect, and a few of the rough edges are downright weird considering the overall level of polish (uploading a “.htm” file receipt gives you an error message, while “.html” works just fine). But they did at least six things right, and those six things are relevant for lots of different applications:

  1. Make it brain-dead easy to start. I typed in my email address and was done. They sent me an email which I later clicked through to set my password. There was zero friction, which is incredibly important. I could also have logged in with my Google credentials, which is a nice touch – but this was actually faster.
  2. Make it easy to explore. The home screen is a series of big boxes identifying common interests for new users. I’d heard about the mobile tool first, and it was one click to learn more. The basic navigation is very simple, and maps to things like “Receipts”.
  3. Use Mobile for the right things. This is really important. I do not want to create an expense report on my Android phone. I probably don’t want to create one on my iPad either. When I’m mobile, I want to do one thing: easily record expenses. So the mobile app does that very well – I can photograph a receipt with my phone, and/or enter expense details on a simple screen. There are two big buttons when I open the application, one for each option. It’s very responsive. And I don’t need to keep the small receipts anymore.
  4. Integrate seamlessly, but don’t make me do it first. Another box on the home page is “Link Credit Cards.” It took two minutes to link in my American Express, and then I had a huge list of transactions to choose from.
  5. Give me multiple avenues to learn the software. I can add expenses to a report from the report, or I can look at expenses and add them to a report. Same with receipts. I never found myself having to go back into the wrong area of the application. When I looked for a feature, it was there.
  6. Don’t make me learn the whole thing. Expensify supports “policies” for corporate expenses. There are some other features there too around submissions and approvals. I don’t need those yet, so I didn’t have to use them, learn about them, or worry about them. As it happens I have looked at them, and they’ll be useful in the future – I just don’t need them now. Complexity kills, especially when you want casual users to adopt a system without external support. Expensify landed me as a customer because I was able to finish an expense report in 15% of the time it would have otherwise taken.

They also do a good job of thinking about ways that new technology lets you change the underlying workflow of an old process. In this case, it’s expense reports for receipts under $75. If you link a credit card, you can import expenses and the system generates an “eReceipt” for that charge. Expensify prints it in the report and adds a bar-code, and it can be verified with the site later. The company will stand behind the fact that the expense was imported from a credit card statement, up to and including during an audit from the IRS. If your corporation accepts the eReceipts, you can stop carrying around those little printouts from taxis. This is something that the old Ariba system – or any non-cloud expense account system – simply can’t provide, because it relies upon the trusted connection to the credit card company, and on Expensify’s willingness to stand behind the integrity of that data.

When turning workflows into products, it makes to ask what capabilities are available now that weren’t available on paper or weren’t possible electronically with the technology of a few years ago. The eReceipts are a great example of this. Development for the iPad should be triggering a lot more of this kind of lateral thinking, as we all adjust to touch-and-swipe interfaces instead of keyboards and form fields.

Naturally there are a few things Expensify can improve on. I’m glad I didn’t need to take a training course to use the tool, but a five-point introduction to the core concepts would have been nice. The most opaque thing about the system is the relationship between receipts and expenses. It’s not actually all that hard to figure out, and the system gives you helpful messages. But an introduction presentation would have made things clear from the get-go. Dropbox does a great job with that.

Any time you’re asking users to think about the attributes of a data model you’re asking for a certain amount of trouble. In this case, the idea of “reimbursable” and “unreimbursable” expenses also needed some clarification. Since I was in consultant mode when I was doing today’s reports there’s no concept of “unreimbursable” – but I’d unclicked the default when I was linking my credit card because I thought that leaving it as “reimbursable” would make more work for me as I filtered through expense lists. It turns out this is useful for corporate cards, which makes sense – but I’ve never carried a corporate card where I didn’t get the bill myself (oddly, this was true even when I worked for the Federal government).

The bottom line: a very useful service and a great source of ideas for making other web applications easier to use. Oh, Expensify guys -please add an “email receipt” feature like TripIt’s, if you haven’t already.

Get Microsoft’s PDF add-on now

I use a set of sketchy Visio stencils to create mockups for the web applications we build here, and there have been two practical pitfalls to the sketchy stencil strategy.  First, the sketchy stencils created larger than expected print jobs — I’ve had a few close calls, nervously hovering over the color printer before a client meeting, waiting for my mockups to emerge.  Second, when exporting the mockups to PDF (through Adobe’s PDFMaker add-on), the PDF files tend to be large, and printing from the PDFs takes even longer.

I learned recently that Microsoft provides its own Save as PDF add-on for Office 2007, so I tried it out, and was very pleasantly surprised.  Microsoft’s PDF generator:

  • is free (unlike Acrobat)
  • generates PDFs in the blink of an eye (rather than a minute or so with Acrobat)
  • PDFs are 1/2 to 1/4 the size (based on my casual observations)
  • printing from the Microsoft-made PDFs is incredibly fast

That last printing point is a big one, since it allows me to circumvent Visio’s embarassing inability to perform simple print functions, like collating multiple copies.  (Rather than print in Visio, I can make a PDF and print from Acrobat Reader with ease.)

The Whiteside Rules for Biotech Entrepreneurs

On Thursday Evan and I spent the afternoon at the first session of the Harvard Medical School Dean’s Symposium. The topic was “Challenges to Successful Innovation and Translation” of medical research, and the highlight was a talk by Professor George Whitesides.  Dr. Whitesides is one of those very interesting products of Cambridge, MA – he’s written over 950 papers, and co-founded twelve companies, including Geltex (which was sold a few years ago for $1.3 billion) and a little biotech named Genzyme. So when he talks, it’s worth listening.

After his talk I asked him if it would be all right if I shared “Whitesides’ Rules” on this blog. He agreed, provided that I referred to them as “Uncle George’s Homey Rules for Entrepreneurs.”  So here’s Uncle George’s homespun advice for entrepreneurs. I’ve refrained from adding my own commentary, other than to type up my notes from the talk (and thus take no credit for various homey aphorisms):

  1. There are three strategies for entrepreneurship. You can solve a problem, you can develop a technology, or you can imitate or improve on something that already exists. Solving a problem is best, and keep in mind the difference between wants and needs in mind when you select that problem. A cure for Alzheimer’s is a need. A new car, less so.
  2. Radically new ideas are much harder than a “me too.” And they may or may not be more profitable and important. Genetic engineering was going to change drug development thirty years ago. It’s only now beginning to have a real impact.
  3. Finish the science before you start the company. Ideally, prototype the product and try selling it.  It’s easy to do engineering on a budget and on a schedule. Science is a little trickier.
  4. A customer is someone who will pay you money, and product is what s/he will pay you for. The most intimate, shared human experience is writing a check.
  5. Spend time as an apprentice. Learn from people who know – and have already made many expensive mistakes.
  6. Use Venture Capital as little as possible. Venture advice can sometimes be very helpful, but remember the overvaluation of capital. VCs get most of the money.
  7. Make simplicity an explicit strategy. But don’t go overboard. Start as simple as possible, then make it simpler.
  8. Remember the Money. If research is $1, development is $10-$100 and manufacturing is $100-1000.
  9. Technical development and market development are inseparable. Most scientists aren’t socially acceptable. Take them to the meeting, but use duct tape.
  10. Regulatory agencies are motivated to avoid risk. Nobody ever lost their job for not approving a product.
  11. Cash may rule, but time and risk discounted cash flow decides. Slow and uncertain are both bad.
  12. Cost of capital differentiates. Small companies are creative and have a high cost of capital. Large companies aren’t creative, but have a lot of cheap money. Synergy would be ideal.
  13. Learn elementary accounting. DCF, RONA, ROI, EBIT(DA) and CAPEX. Otherwise the business people will see you as shark food.
  14. Right now, and for 3-5 years or more, IPOs will be difficult or impossible. Plausible exit strategies are eveloping a company that sells stuff, or selling the company.

And that is what Dr. Whitesides thinks bioentrepreneurs should know.  Not all of these apply to Health IT, regular IT, and entrepreneurial activities that don’t have a science component. But most of them do.

Learning to follow directions

I had a meeting at Beth Israel early this afternoon, and wanted to go to the Harvard Medical School Dean’s Symposium‘s first session, which was at Harvard Business School at 4:30.  That left me with slightly too little time to meaningfully return to the office. Since it was a nice day, Evan and I decided we’d just walk from HMS over to HBS and use it as an opportunity for a walking meeting.

As we walked along the Charles River, we came across the following example of Not Following Instructions:

Not Following Instructions

I wish that I could say this was an example of bad design. But I think I have to go with user error. The close-up is worth sharing:

Need a can-opener?

I’ll talk about the actual Symposium tomorrow. For now, just be glad you’re not that truck driver.

This Twitter Thing

Last Tuesday I attended HealthCamp Boston, a really excellent 1-day “unconference” organized by the extremely energetic Mark Scrimshire.  The unconference format is really fantastic, provided that you get the right people in the room at the right time. In this case, we did, and the user-generated agenda included an excellent discussion on the new HHS rules for PHRs lead by David Harlow of HealthBlawg, a deep dive into design by Claudio Luis Vera, a session on consumer and clinician PHR engagement that John Moore and I put together (with John providing most of the good bits) and a discussion of Twitter’s role in social healthcare media led by Jen McCabe Gorman. It was great to finally meet some people I only knew from online, and I definitely made some new friends (including beers and a fascinating discussion after the meeting with Vivek Garg of TrialX). I definitely recommend these events, and at $25 a person it’s a lot cheaper than normal conference. We’ll be organizing one on software design in healthcare at HMS in the very near future.

I didn’t actually make it to Jen’s presentation on Twitter – I was over with the pharma crowd. But last Tuesday was the day I figured out what Twitter was good for. It’s not that I was a Twitterphobe, but I’d signed up because all the cool kids seemed to be doing it. I followed a bunch of people, and set up this blog to advertise posts as tweets, and that was about it.

The eureka moment came during the first session of the day.  Since attendees were encouraged to tweet about the event, I brought up Twitter on my laptop and started writing tweets that summarized the interesting points of the discussion, using the #hcbos hash tag to identify them to the other conference-goers and interested outsiders.  Then I started following the hash tag in another window, and saw a few other people in the room were also tweeting. And here’s the cool bit – we were generally picking up on the same stuff. Not completely, but with at least 80% overlap. And just like that, Twitter was validated as an information source. I just had to see it in action.

For the rest of the conference I watched the hash tag and picked up some of the key sentiments from the sessions I missed. The next two days I followed the tags for the Health 2.0 conference, which I hadn’t attended. While I certainly missed the details, I definitely picked up the flavor of the event.  And in the week since, it’s been a great way to maintain contact with all the new people I met at #hcbos.

So that’s that – I’m not yet a complete Twitter addict, but I think I get it. Of course, now that I’m here, I’m seeing the dark side as well, as it becomes another vector for spreading swine-flu hysteria. As is often the case , xkcd gets to the heart of it.

Better care through empathy

Steve Portigal at Core77 mentions last Monday’s article in the New York Times about a new study from Israel that shows radiologists write more thorough reports when a file includes the patient’s photograph.  Sequestered in dark rooms, surrounded by computers, radiologists rarely meet their patients — being able to see even a glimpse of humanity among x-rays, CT scans, and MRIs seems to create a beneficial connection between doctor and patient that otherwise wouldn’t exist.

This new study opens up additional areas of research: do photographs improve distance medicine? What about surgical procedures when the patient’s face is blocked by a curtain? Or online pharmacies that never meet face-to-face with their customers?

Can PCHRs provide the data to personalize a medical encounter?

Back in 2006, when we redesigned the personal health data model for Indivo 3, I successfully lobbied to include a photo element in the patient’s contact information document.  At the time, I just thought it was logical to have a picture of the patient in the patient’s record.  Unfortunately, other development tasks took priority over integrating the photo feature into the reference UI.  The idea languished until I did some designing exercises for a next-generation PCHR user interface several months ago. My approach was to learn from the success of social networking systems to make a PCHR interface more human-centered and engaging. In our earlier work, we had been thinking so much about making PCHRs secure — it was fun to think solely about making them usable.

Including a photo in a PCHR patient profile

Including a photo in a PCHR patient profile

A list of family members with identifying photos

A list of family members with identifying photos

Now here’s where things could get interesting. Our interaction design process relies heavily on personas — composite visualizations of key users built with the ethnographic data we collect in our field research (interviews, surveys, etc.). It helps our team rally around our users as we design and build software.  Every design decision gets filtered through our personas.  “How would David build his research team? Does he think about roles, or does he already have collaborators in mind?”

An example of a persona from our grant collaboration project

An example of a persona from our grant collaboration project

Could a medical “persona” have the same impact in the delivery of healthcare?  Patient summaries as they exist today (and to the extent I’ve seen them) stick to core data like procedures, problems, lab tests, and immunizations. Primary care physicians, who we expect to develop a fuller, more human view of their patients, have increasingly less time to devote to social interaction. In our design personas we include sections for motivations, behaviors, and obstacles — might such information help caregivers move beyond the minutia of clinical “tasks” to, dare I say, “goal-directed” medicine?

Cufón: A step closer to web fonts support

About ten years ago, I first played with Microsoft’s font-embedding technology for the web, WEFT.   It was pretty simple — generate a condensed version of your web page’s font files, add some code to embed them in your HTML, and then any lucky user of Internet Explorer 4+ could see your site just the way you intended it.

Like any good web innovation from Microsoft, it wasn’t supported by rival browsers, so I forgot about it for a while, checking in every now and then for some progress. In the meantime, I generated headlines and buttons as images, even going so far as to use a Comic Sans with Windows 95).

Of course, I also watched in disgust as the web community foolishly flocked to

Then, last week, I read about Cufón on Cameron Moll’s blog.  It’s a pure JavaScript/CSS solution for rendering text with your desired typeface, which is used just like WEFT, only the font conversion occurs through an online script rather than desktop software.  Cameron lists Cufon’s drawbacks as compared to sIFR, but they seem pretty reasonable given its advantages: Cufón does not require third-party client software, it zooms cleanly within the browser, and it’s very easy to work with.

WEFT hasn’t died, though.  Implementation is still perilous, and font licensing issues still hamper it, but Firefox 3.1 3.5 will support the @font-face rule.

All this discussion raises the question: is it worth it?  I love typography; in fact, I’m teased at the office for trying to use such wacky, non-traditional fonts like Helvetica in our PowerPoint presentations.  On the web, though, I don’t think the benefits of custom fonts outweigh the costs to usability and complexity of implementation.  There are some great examples of web typography that carefully use default fonts. I think I’ll wait for ubiquitous, consistently cross-browser support of web-embeddable fonts before wading those waters again.