My iOS developers are actually eating lunch next to me giving snarky comments as I write this, "Be sure to include things like 'Gods among men' and stuff like that..."

Although I'd love to be the designer who pulls the latest build and fires up X-code to test incremental changes, I'm not there yet.

Here's my general philosophy, though not that I'm claiming it is the best:

When I worked in design agencies, we would include a specific number of review rounds in a client's contract. Usually it was about three. I treat working with iOS devs (or any engineers) the same way. I am their client and they are the agency: I get a certain number of attempts to give them feedback so that their execution is perfect, but beyond that it's scope creep.

First I give them comps, animations, and prototypes with specs called out where necessary. I don't spec out every detail - since that would easily double the delivery time - only the relevant changes. That is usually enough for them to get 90% of the way there.

Then it's time for those reviews. We schedule a side-by-side "polish" session (or two or three) where I open the comps on my screen, they open the build on theirs, and we play "spot the difference" like it's Highlights magazine. I call out the inevitable discrepancies, keeping in mind that they are paid to be really good at engineering, not necessarily noticing subtle changes in leading, or just how many milliseconds that transition takes.

We each have respect for each other's talents, so when I point out small changes, they understand that those little things are important. At the same time, I pay attention to their stress level and recognize that they are human. If they can't make each of the 15 small changes, then I ask them what they believe they can do, and trust them on it. After a certain point, it just needs to ship and we move on.

This has worked well for accomplishing the most good over the long term, and being able to enjoy coming to work.

I hope that helps, and I look forward to learning from other people regarding how they handle the process.

Very useful links, thanks Kevin. Mind-expanding quote from the Hoodie article: "We can't keep building apps...where a temporary disconnection or slow service is regarded as a problem and communicated as an error."

Thanks Ed, I like what you said about muscle-memory, that a user obviously isn't thoroughly examining the UI every time they use the app.

Really cogent points here Jake. I agree, industry-wide it doesn't seem like we have put much effort into the experience with an unreliable connection. "Minimally disruptive" seems like a good policy.

Reminds me of this article by Daniel Sauble: https://medium.com/user-experience-design-1/offline-93c2f8396124

Thanks for a great analogy Miguel!

Regarding apps that disable nothing, but throw an error when you press a button: I like the idea of giving the user a sense of control, however it might be frustrating to "guess and check" to find out what is still working.

You make a really convincing point that we shouldn't be hiding things the user has come to expect. Even if the bus isn't coming, you should still know where it would be under normal circumstances. Communication seems to be the key here, let them know that things are disabled because they are offline, but don't make things disappear!

Some people use a comma instead of the period for numbers. So he charges "$65.00" per hour. Threw me too!

Going to Meetups has yielded results for me. Don't go to design-focused ones, but rather ones oriented toward entrepreneurs. There are lots of founders walking around, but few other types. Founders light up when they meet someone with design skill. All the business cards.

Plug: if you're in the SF area, StudyBlue is looking for a part time marketing designer. I'm a designer there, pretty cool place. Selective but worth a shot.