What are considered best practices when building apps?

If you're setting out to build an app, you might be wondering what the best practices are so you can take an approach that is likely to lead to success. In this post, I'll hopefully shed some light on that based on what we know today in 2022.

Four key areas of best practices

It's easier to talk about best practices if you think of your app from different angles. The most significant ones are:

• Strategy Best Practices
  The choices you make when deciding what app you will build
  
• Process Best Practices
  How you organise your people and time when building an app
• Design Best Practices
  How you create an app that resonates with its users
• Technology Best Practices
  The platforms and technologies you use 

Rather than write a book here, I'll try and pick out the top 20% of things in each area that will have the most significant impact on your success.

Strategy Best Practices

An app can be a considerable investment, and so it pays to get your ducks lined up first. Here're some tips on that. 

• Have your current business strategy to hand before jumping into app ideas. It helps communicate the why behind the app.
• If you don't have a defined strategy, draw up a light 1-page strategy document that outlines key components of the business strategy. The Strategy Choice Cascade is a handy tool for this.
• If you have an app idea already, imagine you've built it and list out what would need to be true to make it worthwhile. Think about how it impacts the business strategy; what would have to be true about your customers? What would have to be true about your business operations and your competitors?  Are there any concerns or barriers that make you nervous about executing each idea?
• If you see barriers that concern you, accept that it might be better to test some theories rather than build an app. This might mean building prototypes, interviewing stakeholders or conducting surveys. Any kind of research that helps reduce uncertainty. 
• If you don't have ideas for apps already, then you need to find problems to solve or opportunities to exploit relating to your strategy. Then you can generate ideas, identify barriers and resolve them as outlined above. 
• If you can't think of ideas, just fall back to "How might we delight customers whilst making ourselves harder to copy and increasing margins?" to get the ball rolling (ala Gibson Biddle).
• Successful consumer apps are under continuous development because the opportunity keeps growing. If you're not thinking this way, it's worth examining your strategy to see if the opportunity is big enough.

At the end of all this, you should have a mobile strategy aligned with your business strategy where any significant concerns have been tackled. You're now ready to set your process and design an app.

Note: You can learn more about this Design Thinking / Strategy stuff in the IDEO-U Designing Strategy course.

Process Best Practices

This is about how you organise people and processes when building an app.

• After strategy, sketch out your desired timeline, and milestones and also make a risks list. This can be throwaway (or not) but it helps point everyone in the right direction when the work kicks off. 
• Create empowered cross-functional teams that bring designers, marketers, developers, customers and business unit specialists together. Just stick them together and let them solve problems, it saves a lot of lost-in-translation issues.
• Review progress every week or two. If you're researching to remove barriers, review the research. If you're designing prototypes, review the prototypes. If you're building app features, review the progress. 
• Keep your review teams small. Any stakeholder should be able to come along, but reviews work best with 8 people or fewer actively contributing.
• Have one person in the team that has the final say on what gets done next. This is often called the product owner - it's like the CEO of the product.
• Do quality control throughout, not just at the end. Testing apps is crazy hard, so you need constant focus on quality. This includes writing and maintaining test cases.
• Keep specification documents light, and it's more efficient to have the team discover the requirements together rather than having someone capture them and then the rest of the team play catchup.
• High performing teams are ones where there is high trust. Invest time in rapport building and enabling people to speak their minds safely.
• Run discovery, development and quality assurance continuously in parallel. Stage gates slow you down and create friction with handover protocols.
• Try and ship your first app version within six months. This encourages you to keep it small and simple for starters. After that, aim to ship updates weekly or monthly, assuming the app is actively developed (see above why it should be).

Design Best Practices

Design is a broad subject but here are some key best practices to consider.

• See design as both how it looks and how it works, so it's not just a visual thing.
• Don't just design an app. Zoom out and think about the entire end-to-end customer interaction across all channels and touchpoints. App design is service design.
• Co-design with customers. Carry out research, build customer empathy and conduct user testing to avoid making something users reject.
• Don't do all the design up front. You learn so much as the project unfolds, so it can be helpful to spread the design across the entire project and feed in new learning as you go.
• For mobile interfaces, lean on mobile design guidelines, there are amazing design systems by Apple and Google that cover font sizes, item sizes and adaptive interfaces that work on all devices. 
• Don't assume all your customers are on a modern, large phone. Design for the old crappy devices too (unless your customer research contradicts this).
• Think about marketing metrics when designing your app - acquisition, activation, referrals, revenue and retention. 
• Think about marketing tech when designing your app, what will you need to achieve retention and referrals. OneSignal, Amplitude, AppsFlyer etc may all be worth considering.
• Don't obsess over the visual bling too early, customers care about getting things done, and visual polish usually only plays a minor part in overall customer satisfaction.

If you follow these core best practices you should end up with an app that fits well with the business and customers it serves.

Technology Best Practices

• Chose mature, supported and established frameworks and tools where possible. You don't need increased schedule and cost due to poor documentation, bugs and slow support responses.
• Let the tech people choose the tech they are most productive with. 
• There is no best mobile app development stack. Your tech team should be able to pick the right tools for the job. React Native, Flutter, Swift, Kotlin, PWAs, TWAs and Xamarin all have their merits.
• In most apps, it pays to have security experts do penetration testing.
• Consider working to known standards such as OWASP to promote good security practices.
• Some unit tests are usually better than none.
• Don't be tempted by shiny new technologies. Save that for the R&D projects.
• Keep it simple and ship often.

Words of warning

I'm pretty confident in this lot, and it's pretty much the process we help you adopt when working with Pocketworks. That said, I see kick-back in a few areas in practice, so it's worth me pointing a few things out.

Agile can be a leap too far

Firstly, you might not be ready or able to embrace agile work and agile budgets. You might want to define everything up-front, get a quote and then build it. This is common. The thing is, I'm seeing a lot of companies move away from this model because it's affecting their ability to move fast and respond to a fast-changing world. I talk a little bit about this here in a post about Why our Clients choose Product thinking over Project thinking.

Customer-centric design can be scary

Also, not all companies accept customer-centric design where you involve the customer in the design process. Instead, they want to use their own industry knowledge to decide what to give their customers.  We're firmly in the camp that you are not your customer, but you are smart and industry savvy, so there is room to allow the business to shine while involving customers in the design process.

Issues with cross-functional teams

Another area that can be hard to grasp is empowered, cross-functional teams. This is where you make sure the right people are around the table, throw them a problem to solve and check in on the progress as they proceed. It's tough for some people to let go and allow people to crack on, make mistakes, learn, have big wins etc. Deloitte explains the benefits of this here.

Not all apps need continuous development

Finally, much of my thinking is shaped by the fact that we primarily work on never-ending apps that grow yearly. Not all apps have to be like this to be successful. For example, apps for employee efficiency can be more easily "paused" for a few years. Even some consumer apps don't need constant updates to be successful. It all depends on what success means to you. Is your app about being a market leader or simply ticking some necessary boxes?

Reach out to me on LinkedIn (below) if you'd like to discuss.