Mobile, apps and user experience

This topic is for the person commissioning an internal application or a customer portal, not a consumer app for the app stores. The decisions it covers are whether you need an app at all or a web application that works on a phone, and how to find out before anything is built whether the people who will use it can do their jobs with it.

Where to start

• 5 questions you need to ask yourself before developing an app is the brief you should be able to answer before talking to anyone: what it is for, whether it must be an app, what it connects to and who will own it.
• Native app vs web app compares native, cross-platform, progressive web app and plain web application for a business system, and says how to choose.
• 5 essential features your enterprise mobile app needs lists what specifications for staff apps usually miss, such as company sign-in, a shared API, server-side permissions and working offline.
• The importance of prototyping before software is built explains what a prototype settles before the build and what to ask a supplier about theirs.

What people get wrong

The first mistake is starting from the words we need an app. For staff and for customers, the job is usually a web application that works well on a phone: one system to build, one to update, no app store to go through and nothing to install. A native app earns its extra cost when it needs the camera or has to work offline in the field, and the article on which to build first shows how to build the web application so that an app can follow later without starting again.

The second is treating design as what the screens look like. For an internal system, the design question is whether a new member of staff can do the job without training, and whether the task people do most often takes the fewest steps. That is user experience, and it is settled by watching people work before anything is drawn, not by choosing colours. The articles on the difference between UI and UX design and on personas show what to ask for and what to check.

The third is approving a mock-up and expecting the software to behave like it. A mock-up shows appearance. A prototype shows behaviour, and it is the cheapest place to find out that a screen has the wrong fields or the wrong order. The article on wireframes, mock-ups and prototypes says what you are approving at each stage and which you can skip.

How this connects to our work

The systems this topic is about, internal applications and customer portals, are the kind CodeFirst builds as bespoke software at a fixed price to an agreed scope, with the scope settled before the build so that the questions above are answered before they cost anything. A customer portal built on the system you already have is one of the fixed-price packages, and the package page sets out what it includes.