2

Ask DN: How do you work with iOS developers?

5 years ago from , Product Designer at Blue Apron

As a product designer, I really really love to sketch, do some light mocks, and dive into scaffolding/interactive prototyping as fast as I can to get a better feel for the product.

When working specifically for iOS, there's obviously a ton of products you can use to make interactive prototypes to gather feedback and get a sense of how it feels/works, but ultimately you'll need to work with a developer to implement everything.

My question is - there's a lot that I do after the interactive prototyping phase in production level code (animations, tweaks, etc), but with iOS, not being competent in the native language I can get in there and have the granular level of control, and instead I'm stuck with delivering specs and explaining to the developer the small nuances and details that are easily missed. How do you work with iOS developers in a way that makes the process more seamless and collaborative and less like handing things off to be created?

3 comments

  • Stefan Rauch, 5 years ago

    Pixate

    0 points
  • Devon LatzenDevon Latzen, 5 years ago

    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.

    0 points
    • Win LinWin Lin, 5 years ago

      Hey Devon, thanks for the response! I agree to a certain degree with you, but I believe that relationship is still somewhat flawed and will not result in a well-developed product. Like you mentioned, I'm really used to pulling down the app in Github, getting it running locally, and being able to be in the code to fiddle around and tweak things on my own is a huge plus. I guess I may have answered my own question that nothing can really replace that but I was hoping for some answers that could get close to that kind of workflow.

      Thank you!

      0 points