11–15 of 15 posts
One UI that solved navigation in a satisfactory way is Windows Phone. Sliding sideways to navigate back and forth, and expanding details in place on tap just makes sense.
> We neglected to consider the importance of other categories of tasks, such as [viewing, updating] These kinds of tasks were actually more common than creation — especially on mobile... Sounds like a business analysis problem, then. Don't build for what you think your users will do or what they tell you they'll do, build for what they actually do. I'm not sure this was a "design" problem per se.
Most iPhone apps UIs are a mess because they include multitudes of interactions (tap to open a panel, slide up to open a panel, slide to the side to open a menu), and layers upon layers of panels without an easy to navigate back and forth. It's hell. One UI that solved navigation in a satisfactory way is Windows Phone. Sliding sideways to navigate back and forth, and expanding details in place on tap just makes sense…
> We neglected to consider the importance of other categories of tasks, such as [viewing, updating] These kinds of tasks were actually more common than creation — especially on mobile... Sounds like a business analysis problem, then. Don't build for what you think your users will do or what they tell you they'll do, build for what they actually do. I'm not sure this was a "design" problem per se.
What a user will do at their computer will often be different than what they do on a mobile application for the same application. It can be hard to predict even if you do ask your users what they think they would use on a mobile application.
You have a website that does a specific thing. You, presumably, have analytics that show what users do on that site. In the case of Freshbooks you'd come up with some kind of ratio about invoices -- say, for every 1 invoice created, 10 are viewed (that seems probably like it's close to the truth, if anything the ratio of views would be higher).
To then turn around and make creation of invoices the main interaction point on the app, despite everything you know about your site's visitors, seems like a logical misstep.
I hope I don't come off needlessly critical. My point is that you should have data to support changing interaction paradigms.
Another thought is maybe the Freshbooks folks thought the app would be an avenue for customer acquisition, in which case creating an invoice would certainly be the first thing they do (because new customers have no old invoices to view).
Very insightful. Each point seems obvious after the fact, but it's good to get some validation on this 'obviousness'. How do you handle the reports after login? Is it just a webview presenting the same content as the web app? I assume it's not too js heavy, so you don't run into performance issues?
Avrum from FreshBooks here (one of the authors of the post). After login, the 'Create Account' and 'Login' buttons are replaced with two links: 'Email me a link to Reports' and 'View Reports in Safari'. The primary call-to-action is the email because we recognize that the viewing experience for a traditional accounting report is still best on a computer (we actually say that in the copy). That said, if you need acces…