> 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.
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.
Maybe, but a massive change in interaction in this case seems like an odd logical leap to me.
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).
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.