Mobile MVPs done by lone developers on a contract basis should be about getting something palatable and pleasant that works
Truth be told, something palatable and pleasant that works can be a very, very high bar from a UX perspective. When software collides with the real world, you get a lot of complexity. Even organizations the size of Google and Apple can't produce a Maps app that doesn't do wacky stuff that seems designed to frustrate the user while trying to get someone killed. By comparison, how something looks is dirt cheap. (As usual, it's far cheaper to signal quality than it is to build it.)
When it has to deal with the "real world," mobile QA and UX is hard, and doing it to a high level is probably greatly underestimated in cost while being quite expensive. They say a picture is a thousand words, and seeing it yourself is a few more orders of magnitude. If your only feedback is logging/callbacks/snippets of text from users, you're only getting a small sliver of the true picture.
For Android implementations, if you pay attention to the Material Design guidelines, even if you don't have a good designer on the team, it probably won't suck. It might be pedestrian and form-oriented, with less direct manipulation than it should. But it won't look awful.
This. For design-challenged people like me those guidelines are lifesavers. Ironically, I'm not a big fan of Material personally but it helps a lot to have these kind of guidelines handed down to me.
Your maps example is a straw man - everyone knows Maps is incredibly complex - not a small MVP. And your point about how hard it is to get things right further exemplifies my point which is not to get too caught up in pixel perfect details. There's no time/money/energy for that.
If your bar is too high on the UX side, as a lone contract programmer who is NOT the designer, you probably will have the same problems shipping as the person described in the article. Real artists ship. Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
Your maps example is a straw man - everyone knows Maps is incredibly complex - not a small MVP.
Not at all a straw man. Maps might be much, much larger than a small MVP, but Google and Apple have a lot more resources than a lone contract developer. You are the one getting caught up with scale. I'm talking about the increased complexity of apps when they have to bump up against the real world. I've been greatly offended and materially affected by seemingly arbitrary choices made by a developer on a username field. Namely, that starting to edit the username field would blank out the password field, instead of doing this on start-edit of the password field. In a time critical situation on low-bandwidth, this can leave a user with a password vault cursing, high and dry, while the app starts this kafkaesque cycle of doing the most annoying thing.
Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
If the aim is to make a substantive tool that stands up to real-world complexity in UX, someone, somewhere is going to have to spend a lot of time testing the heck out of it and make careful observations. Otherwise, the lone consultant is just going to check off the requirements, call it a day, and bill. The only alternative is to be really good about feedback, and implement in such a way that corrections can be distributed in a matter of a few hours or less.
Citation, please. I deal with clients on a regular basis who think that software with 20+ years of time invested can be duplicated by 1-2 engineers working for 3-6 months.
Earlier today, I had to give a rough estimate on writing a custom app that can read, write, share and sync arbitrary CAD files, and explain why building all of that might not be the best approach.
Truth be told, something palatable and pleasant that works can be a very, very high bar from a UX perspective. When software collides with the real world, you get a lot of complexity. Even organizations the size of Google and Apple can't produce a Maps app that doesn't do wacky stuff that seems designed to frustrate the user while trying to get someone killed. By comparison, how something looks is dirt cheap. (As usual, it's far cheaper to signal quality than it is to build it.)
When it has to deal with the "real world," mobile QA and UX is hard, and doing it to a high level is probably greatly underestimated in cost while being quite expensive. They say a picture is a thousand words, and seeing it yourself is a few more orders of magnitude. If your only feedback is logging/callbacks/snippets of text from users, you're only getting a small sliver of the true picture.