The best strategy for early-stage design of an iOS app?

February 27, 2017 4:09 PM

I'm starting a new job with a funded startup as the sole designer of a new iOS app. What approach should I take now (tools, strategies) to make this product a success later?

Some notes:

• I've designed apps and websites for years, but it's been client work with well established branding and best practices already in place.
• The job I'm starting in a week as employee #1 has no existing product or branding yet—all that will be my responsibility.
• This will be a highly functional app that could compete with services like Dropbox. It will take some time to get it right.

My (admittedly mediocre) approach in the past has been to dive right into polished mockups after meeting with a client, but this is different. I want to do it the right way. I think it will be weeks before I actually design anything. I want to get the order of operations right.

In the meantime—what are the best ways to prepare and set myself up for success?

I know I want to create a document with personas for 2-3 particular use-cases. I want to create a roadmap for the MVP design and set expectations. I want to look at competing apps and take screenshots and create moodboards. Then eventually some wireframes and user flows, which aren't things I've often done (sadly).

What other non-mockup approaches I should take to really research and define this product before getting started with designs? Any other tools or templates that have been helpful to you for making this a smooth process and mapping things out clearly for the founders and investors?

posted by critzer to Technology (4 answers total)

I do this for a living. Here are some additional things I do:

• Before putting any pen to paper at all, talk to people who might potentially use the product about their life and where this product might fit. Don't just ask them what they want, but see what patterns emerge about their behavior and pain points, and find where you might do something better than their current solutions.
• Prototype, prototype, prototype. Static mockups are great and all but prototypes will get you closer. Even simple clickthroughs are fine things to test with real humans to iron out complex flows, especially for a task-driven application like yours.
• Align on a clear set of goals for the application. What do your internal stakeholders actually care about? Downloads? Daily actives? Advertising opportunity?
• Use your team. Get on the same page with engineers and get them building things ASAP, even if you don't know exactly what you're doing yet. Talk to marketing folks ASAP, even if you don't know what the brand looks like. This is different from agency/freelance work, where sometimes you can go into a hole and come out with an idea, and move on to the next client.

Have fun!
posted by thirdletter at 4:28 PM on February 27, 2017 [6 favorites]

I know I want to create a document with personas for 2-3 particular use-cases. I want to create a roadmap for the MVP design and set expectations. I want to look at competing apps and take screenshots and create moodboards. Then eventually some wireframes and user flows, which aren't things I've often done (sadly).

These sound like the right things to me but they're not in the right order.
Start off with wireframes, user flows, & personas to organize your information as you find out:
Why is the user opening up the app
Where are they when they're doing this
What information do they need to provide
What information is the app going to spit back
What does all this look like at a very basic level & does it feel right sketched out. Does it make sense & feel good when you play around with it. Does it make sense & feel good when you put it in front of other people. Clickable prototypes are great for this.

Then do your MVP & expectations as you get a feel for what's critical to include for user success

Then finally after all that's done you can look at competitors, mood boards, visual design and that fun stuff.
posted by bleep at 9:14 PM on February 27, 2017 [1 favorite]

i seriously advise you to hire an equally or more competent engineer to check you on your bad ideas. without a reliable gut check, for sure the product goes out the door with a few terrible design choices.

The amazing Brian Foote noted long ago, "You can't get reusable code through superior insight and sheer force-of-will." I'd extend that to good design.

lennon/mccartney, weir/garcia, hetfield/hammet, strummer/jones, jobs/wozniak, page/brin...
posted by j_curiouser at 10:12 PM on February 27, 2017 [1 favorite]

Communication is everything. Talk as much and as often as you can. Document proposals (scenarios/personnas etc) but also make sure you keep a trail of decision and changes (this is easier if design docs are in source control, but it's not always possible). Share drafts - don't work for too long on a document without checking in with the rest of the team, until you have a good feel for how you communicate (when we hired our first designer, we were guilty of this at first - we quickly realized it was better to talk almost every hour first, then over time, as we learned to work together, we could spend a day or two not interacting...)
As far as tools, we went as far as to have potential users interact with a marvel mockup, and draw conclusions from that before starting to build the first line of code.
I wouldn't focus too much on competing apps, unless it's a mature market. It's only useful if you're aiming to recruit switchers - but for most people, they won't be comparing between app A and app B, it'll be more about not using an app and using one.
It's hard if you're the only developer, but having someone else gut-check you code is always useful. It's also good to document what you won't be implementing for now, as well as what should go in the app vs the server if there's a server component, etc
Push hard for features users want in the MVP, and drop everything the team wants to include because of its potential or just because they like it. Our experience has been that end users always prefer less features and a more robust "cognitive model" for the app, rather than advanced but half baked features.
Finally, wording is as important as the rest of the design. It's often useful to allow for testing of wording for features or help affordances, and it can be counter intuitive (even on things such as a signup form, we had some users confused by what to put in the "Name" field...)

Good luck with your app ! It'll be an exciting journey.
posted by motdiem2 at 9:55 AM on March 1, 2017