Posts tagged ‘process

The 6 Stages of App Development - Part 2

In Part 1 of this series I outlined the reasons why we follow a methodical approach to developing apps for clients and discussed the intial stages: analysing the problem, feature design and interaction design.

This post covers the final stages leading up to release: visual design, building the app and testing.

Stage 4 - Visual Design

With a set of features laid out for our app, we can start to add polish to how it looks. During this design phase we tend to produce mockups of how the app will look in Photoshop and work closely with the client to make sure everyone is happy with the style, colours and branding.

It’s important to remember that these mockups aren’t exactly how the final app will look. Due to the range of screen sizes and orientations, this stage is more about creating a guide for common elements used throughout the app. Still, focusing on the major views as a whole lets us design elements like toolbars and buttons in the context they’ll be used.

iBeacon App Mockup

When we reach this stage it’s easy to think that the bulk of the hard work has been done; we’ve planned out exactly what the app will do and here it is on screen looking great! In fact, there is still a lot of work to do converting these static mockups into a stable, functional app.

Stage 5 - Building the App

This stage - turning our designed app into a reality - is the one that will involve the client the least. We’ll need to get our heads down and write the code that detects the user’s actions (e.g. a button tap or swipe) and does something in response. It might be as easy as presenting the next view or something very complex like running a real-time 3D simulation but it all needs to be programmed.

In this stage we’ll also build any back-end infrastructure that the app needs to communicate with. This is usually a web server that the app sends and receives data to/from.

Progress updates might not be as exciting for a week or two but, given time, we’ll produce a working app that we can install on a device for you to test.

Stage 6 - Testing

Finally, with a working version of the app built, we’re ready to start putting it through its paces.

For saftey-critical applications we will spend time writing automated tests that cover all possible tasks required of the app and can be run at high-speed often. This helps us ensure changes we make in the future don’t break existing functionality elsewhere.

More commonly though, this stage will involve sitting down with the end-user (be that you or potential customers) and observing them and asking questions. We can do a private release targetted at specific email addresses.

We’ll also set up analytics so that we can collect data on user activity. This will help us uncover bugs and see what features are being used most.


So that’s it! A well thought out, good looking, first version of your app. Hopefully it will have gone down well with test subjects and be ready for a wider launch.

At each stage, especially based on feedback in Stage 6, we can revisit any of the earlier stages of development and rethink something. It might be that users are put off by the colours used so we jump back to Stage 4 and redesign something. Maybe testers flag up a vital missing feature that we can go back to Stage 2 and plan.

The whole process is flexible, but using this framework we can be sure that things progress in a logical way towards a quality app.


The 6 Stages of App Development - Part 1

With each business that comes to us with an idea for an app or a problem they are facing, we tend to approach designing and building the solution in a similar way. Methodically breaking things down helps us articulate timescales as well as keep track of where we’re heading with development.

Each project is unique and requires flexibility within this loose framework. In a lot of cases we’ll collaborate with third parties to complete all or part of a stage. Sometimes the plan will change mid-way through development and we’ll adapt by revisiting a previous stage or cycling through a number of them for a few iterations. Nothing is nailed down, but hopefully this will give you an insight into the milestones a lot of our projects pass in the lead-up to release.

Stage 1 - The Problem/Idea

Before we can start thinking about a software solution, it’s important to really get our heads around what it is we’re solving. In a lot of cases, companies come to us with a pretty clear idea of what they want building. We like to get together and discuss the motivation behind the project in detail before we get started for a number of reasons:

  • We need to understand your business to appreciate how the problem affects you and what kind of software would be appropriate.
  • What one person perceives to be the problem might not always turn out to be the thing that needs addressing directly. You know your business better than anyone, but sometimes it takes an outsider to tease out the root cause or a higher-level issue that can be overlooked in the day-to-day running of a company.
  • Sometimes the vision for an app is just not feasible (especially within budget and time constraints). Equally, there might be a solution you hadn’t considered possible. As technical experts we can help analyse the problem in the context of what apps, and the platforms they run on, are capable of.

Stage 2 - Feature Design

Once we have nailed down the problem or need that our application is going to address, we can start designing a solution. Is it going to run natively on a mobile or in a web browser? What operating systems should be supported? Exactly what will users be able to do with the software?

In almost every case, we suggest reducing the scope of an application right down to the bare essentials and focusing on getting those few features right for a first release. This is called a Minimum Viable Product (MVP) and allows us to get something useful into people’s hands as soon as possible. That way, users can benefit from our solution and we get valuable feedback to guide further development, informing decisions and saving money in the long run.

Stage 3 - Interaction Design

Now we know what form the software is going to take and what the first version will do, we can start considering how users will interact with it, commonly referred to as User Experience (UX). To do this, we tend to produce ‘wireframes’ - low-fidelity mockups of the different views the application might have and how the user will get from one to the other while completing a task. While only made up of boxes, lines and text, the wireframes are coupled with notes on how elements might react to user actions.

Example of wireframes

After plenty of iteration with the client, the wireframes should eventually provide a complete overview of the layout of the application. They should be detailed enough to demonstrate how a user would navigate the software to complete any task we have chosen to cover in our MVP.


That’s all for part one. In part two I’ll cover visual design, programming and testing.

Post Archive

2014

December

2013

December

January

2012

October

September