16 Things We Wish We Had Known Before Creating an iPhone App / by Gavin Lau

There’s little in (a designer’s) life that’s more exciting than working on your own projects. Although client projects are definitely challenging and certainly give you insights into worlds that would’ve other wise remained unknown to you, working on your own project can give you an indescribable energy. After just having released two new apps — Ignite and Billy — we wanted to share what we’ve learned about smoothing the process of making an app from a designer point of view.

Although we have read a tons of app design and management focussed articles we weren’t able to find one single article or blog post aimed at helping freelance designers or design studios make their own app. That’s why we decided to write a post for any designer (or anyone for that matter) who’s on the brink of turning his app idea into an actual app to help you make the right choices, to safe time and most of all; inspire!

 

1. Have as many final designs as possible

Working alongside a developer brings along costs. You can keep down those costs by not wanting to change designs or features halfway down the project. In real life you will probably always run into a couple of missing screen states. However, try to think through the entire app-flow and finalize as much screen designs and their various states as possible before you hire a developer. By doing this the developer will be able to estimate realistic costs rather than finding out they will need more time to implement any changes/requests from your side. Naturally sometimes projects work better if you do have the flexibility to make design changes as you go and think of new features, and subsequently have them implemented. However, this scenario is often a better fit for (financially) larger companies.

 

 

2. Hire a developer or make agreements

We have heard so many stories of designers who ‘just wanted to make a cool app’, then started working on it with a developer to subsequently come to the conclusion them and the developer weren’t on the same page. We strongly believe you (designer, or developer for that matter) should never start a project together when you haven’t clearly agreed upon who will do what, who will be the owner of the project and, if applicable, who will earn what and when. Don’t get us wrong, we’re all about collaborating and embracing spontaneity to make great products. We just think business wise it’s in everyone’s interest (and for the product’s sake) to be on the same page beforehand when it comes to assigning responsibilities and settling financial agreements.

 

3. Keep your design files clean

Working together with a developer should result in a synergy. You should both inspire and motivate one another to make the best app ever. What better way to show your goodwill towards a developer than by maintaining clean and organized design files?! Always try to make sure no old versions of screens are in the ‘final’ design files. You will want the developer to be able to quickly find the screen he or she is looking for.

 

 

4. Use a spec tool

Depending on how comfortable the developer is with working in Sketch or Photoshop you can consider either having him/her view your design files for specs and assets or you can use an app like Zeplin. Zeplin helps developers extract whatever they want from your design files whether it’s color codes, assets, measurements or direct code to use in Xcode. Using an app like Zeplin can drastically speed up the project while increasing the joy of the developer for not having to snoop around in any design file. If you’re looking for tool like Zeplin that works with Photoshop we recommend reading our blog post dedicated to finding the best spec tool for Photoshop

 

5. Create a sign up page

Once a developer is on board you can start your marketing plans in the meantime. The most important one: a prelaunch page. Having a prelaunch page is super important for a few reasons. A pre-launch page means an exchange between you and the person who signs up. For the person who signs up, being first makes him/her feel a little special. For you it means gaining an interested crowd before the product is even out. As soon as your app is ready for a (beta) release, you’ll be able to reach those potential customers. We’ve learned it’s super important to get your prelaunch sign-up page online as soon as possible. The sooner it’s online, the more time we’ll have to collect people’s email adress.

 

6. Get help from beta testers

We think you should embrace any help from anyone who signs up to help test your app while it’s in beta. However, even though we genuinely believe their intensions are good, in real life 7 out of 10 people who signed up to beta test won’t (have time to) follow through. This showed in both the TestFlight invitations, new beta build installs and the balance between support tickets added and crash reports. But then again you can’t blame people for not following through on their good intention that drove them to sign up as a beta tester. Heck, we’ve signed up for beta testing a few times where it turned out it took more time to give feedback and address bugs than we had anticipated. That is why we would advice you to have a ‘lot’ of people sign up to beta test so it averages out and you still have a good amount of people actually beta testing your app. Another option we might try for future projects is inviting small focus groups at our office and collect a lot of feedback at once.

Getting information from beta testers can be extremely useful. That is why you should learn how to separate feedback patterns from extremely personal suggestions though. When you get the same valid functional feedback from multiple beta testers that probably means something. Try to find patterns in what multiple beta testers are saying. On the contrary, some beta testers might want to use your app to solve a problem that’s different from the problem your app is supposed to solve. What that means is you should add a feature just because one single person requests that feature.Of course it doesn’t mean you should dismiss their feedback all together. It means it’s up to you to be the judge of how valid someone’s feedback is and how whether your app would benefit from adding a requested feature to your app on the short term. Whatever category someone’s feedback falls into appreciate your beta testers and thanks them for taking the time to help you out.

 

 

7. Make an app flow diagram

Working with app flow diagrams has proven to improve communication between us and the developer, at least for us. You can think of an app flow diagrams as a static blueprint version of a tappable/clickable prototype. App flow diagrams show all of the screens within the app in one single overview whereas a prototypes only shows one screen and screen-transition at a time. Using app flow diagrams can help you and the developer oversee what screens are connected to what screens and which screens are missing. We usually assign unique numbers and names to each screens. By using unique screen numbers and names you’ll be able to avoid any ambiguity when you refer to a specific screen.

 

8. Use a GTD app

When we first started working on our very first iPhone app,Pushh, we didn’t use any Getting Things Done (GTD) app. We just emailed the developer a list of screens and features we wanted Pushh to have. Obviously this wasn’t the way to go about making an app. At Yummygum we always like to name the screen number/name from the app flow diagram and an actionable text. Eg,: 5.1 Active workout — three sets → center align set container on top of card.

 

9. Group to-do’s for developer by theme

Although it can be exciting to see every screen and feature implemented at the same time we found that grouping to-do’s by theme worked best for us and the developer. ‘Theme’ can mean features but can also relate to pulling certain data from the db even though they appear in different screens. If you’re unsure about what defines a theme (IOW’s what can be grouped), discuss with your developer.

 

 

10. Send out betas on a weekly basis

Have you ever signed up to beta test an app and got spammed with new updates on a daily basis? Or maybe worse; once every few weeks? We believe there ought to be a fine balance in between asking too much of your beta testers while on the other hand staying top of mind. If it looks like nothing is happening beta testers might feel like their effort to give feedback won’t matter anyway. We think the sweet spot is around one update per week. Naturally it depends on who your beta tester group is. Team mates or people you know personally will probably put up with a higher beta update frequency as they might feel more involved.

 

 

11. Write proper release notes

Writing release notes can be cumbersome but it’s important keep writing them. For Ignite, our release notes existed of five parts:

  • A short introduction (thanking everyone for beta testing, especially useful for when you don’t add all beta tester signups all at once but when you’re adding new beta testers every build).
  • Newly added (listing all of the functionalities and design elements that weren’t in the previous test build)
  • Improvements (things that aren’t necessarily new but have been improved, think: edited tab-bar icons, speed/performance specific to one feature etc.)
  • Fixes (bugs that no longer exist in the new version)
  • Support (let beta testers know how they can give feedback)

Note that Apple’s TestFlight doesn’t allow any crazy characters or any formatting for Release Notes. It does allow you to use caps and a couple of of UTF-8 characters, like the bullet/circle (•) one that can be useful for lists. As far as the content of the release notes goes, try to find the right balance between going into technical details and on the other hand being too vague. Always try to address any fixed bugs that were reported by beta testers so they know you value their feedback. Looking at the checked off to-do’s on Basecamp gave a good understanding of what had been changed since the last beta.

 

12. Target one screen size at first

One thing that has helped a lot was designing for the most recently released and most sold device screen resolution. Once you are at least 99% sure of what a screen wil look like you can create a version that’s suitable for another/smaller device screen (if the screen doesn’t naturally scale down nicely). Don’t forget to ask potential beta testers what device they have, so you can start by inviting beta testers based on their device first. This way beta testers that have deviating devicesscreen resolution won’t be bothered by screens that have been created with a different device in mind.

 

 

13. Use one support system

We can’t stress this enough. If you have a lot of designer and/or developer friends they will most likely offer to help you beta test your app. Needless to say that is super nice. One downside however is they will probably reach out to you through communication channels other than the way you had in mind. Some of them will send you feedback through iMessage, others through Slack, other will email you, Telegram you, WhatsApp you, you get the gist. Although their feedback is often valid and thought through we suggest asking them to give feedback using the designated support system. This way the feedback will remain visible to the entire team instead of just you. Besides that you’ll have everything neatly organized on one place. If you’re looking for a great support ticket system that can be integrated within your app we recommend Intercom.io. Freshdesk might not be the prettiest tool around but it offers a free plan and it does the job.

 

 

 

14. Get insights from analytic tools and crash reports

When we started beta testing Pushh, we didn’t have any crash reporting tool. We know, that’s sounds crazy and it was! That’s why we believe you should always implement a crash reporting tool. Although a lot of bugs will be reported by beta testers there are always tons of bugs that will be triggered by user scenarios you hadn’t thought of. By extensively testing the app yourself and using a proper crash reporting tool you will help your developer intercept those bugs and understand the crashes to subsequently fix them for a next beta build.

Don’t hesitate to sit down with your developer and discuss what both of you think is the best tool. We recommend you check out Crashprobe to help you decide what tool is able to interpret what type of crash.

Besides tracking crashes, you can’t afford to not track your user’s behavior. Google Analytics for mobile apps does a great job in getting you insights in what screens/button events your users see and interact with. Needless to say the findings of analytics tools could lead to new insights and improved UX decisions.

 

15. Maintain a future roadmap

Having a future road map can drastically improve decision making as to what feature should be added when. It will also help the developer understand what work can be done when it comes to the future of the app. A good developer will get as excited about creating challenging functionalities as much as you get excited by designing what they should look like.

 

 

16. Get ready for launch

After all the hard work you’ve put into bringing your app idea to live in the form of the final/pre-release beta version, you will definitely want to prepare yourself for a proper launch. Make sure you have your marketing products ready.

 

Marketing website

It’s nice to have a marketing website even if it’s just one page. Don’t forget to allow people to download a press kit that includes at least: 1. a couple of good products shots/images, 2. you app icon / logo in multiple sizes (lo-res and hi-res) 3. a plain text file that lists a desciption of what your apps does, credentials, a link to the app on the App Store, your contact details etc.

While you’re working on the website you might think about adding a Frequently Asked Questions page. The more questions potential users will get answered without having to contact you the better.

 

Launch notification email

This is also the perfect time to prep the launch notification email you can send to everyone who subscribed to your sign-up page earlier.

 

Lots of emails

Reach out to as many relevant blogs by sending an brief email that tells your story. By relevant we mean blogs that aims at the same target audience as your app intents to. When writing those emails, mention why you felt like the app needed to exist and let them know on a personal level how passionate you were about creating the app. A personal touch will more likely have you come across as an underdog rather than a large company that merely creates apps just to make a profit.

 

Social media

Letting (potential) users contact you through social media is a must. For a lot of people sending an email can be a hurdle to reach out to you, whereas a tweet of a quick Facebook message is often a more approachable method. On top of that people can shared/re-tweeted your post, extending your reach even further.

 

In conclusion

Of course the success of your app will vary widely depending on the momentum you can build up, the niche your app is in and being able to reach your target audience, timing of competitors etc. Nonetheless we hope these 16 tips will help you make the right choices when creating your (first) own app.

 

 

Source: https://medium.com/yummygum-journal/16-thi...