How to Design Software & Apps People Actually Want to Use

When executives get together and make decisions about how their software should look and behave, focus often drifts away from the person who will use it.  The larger your company, the more removed your designers and developers are from the people who will actually use what they create.

Without the right approach to software design you could end up building:

• App features that no one uses
• A product that requires excessive training and support
• Low adoption rates, or adoption by force rather than enthusiasm
• Unhappy users and lost good will

You certainly don’t want the project you’re championing to fail. Ensuring success, and designing apps that people want to use, requires a commitment to involve your end users in the process.

Rather than dictate the way it should be, your project team involves and empathizes with the people who will actually use the software they’re building. You focus on their needs and problems first. Rather than only on what the business needs from them.

Here’s What Not To Do

Let’s say you’re the COO at a company with a large field team that works outdoors surveying construction sites. Your field team currently documents their findings on paper forms and drops these back at the office at the end of the day.

This creates all sorts of challenges for your team at the office. Problems such as:

• More staff needed just to type hand-written notes into a digital database
• Difficulty reading someone else’s hand-writing
• Paper forms getting lost
• Delays caused when a field employee doesn’t get back to the office the same day

You suggest creating an app for your business that the field team can use to enter this information, rather than paper forms. An app would facilitate an instant upload to your database and remove the need for manual entry later. The idea is approved (!) and developers are hired and given the feature list (i.e. a list of the forms and form fields that need to be implemented).

The mobile application is built, the teams are trained and told to use it. But, after a month you discover that the adoption rate is only at 10% and the office team is complaining about typos and data errors coming in through the digital forms. They want to scrap the app.

Some pretty simple actions could have prevented this.

Here’s How to Design Software & Apps That People Want to Use

Had your project team involved your field team in the design process they would have learned a lot!

Through activities such as job shadowing, asking questions and simple mock-ups or prototypes, your project team would have empathy for users who:

• Spend several months a year working in below freezing temperatures. Therefore: manually typing a lot of information on their smartphone will be difficult, just like it was to write it on paper.
• When it’s sunny outside will experience a lot of glare on their screen. Therefore: high levels of contrast will be needed in the design in order to see the app.
• Have quotas of projects to complete each day and often feel rushed. Therefore: users will take the approach that is fastest, pen and paper may win out if the app is cumbersome and slow.
• Will be using the app on their personal phones. Therefore: will be unhappy about a work-related app that makes heavy use of the data on their limited plans (ex. uploading or downloading photos, heavy use of GPS).
• Are often in remote areas with sketchy Internet access. Therefore: will need the app to work offline.

Armed with this information your software design team is empathetic to the needs of your field team and empowered to do well by them. This will create ‘feature requirements’ you probably hadn’t considered from the board room. Such as:

• Five of the data entry fields you initially required will be removed and auto-filled instead.
• The app design will be tested outside before it’s implemented
• Enable offline access so the app works even without Internet connectivity.
• You may even decide to provide tablets to your field team, or one to each truck, so they can avoid using their own phones and data plans. Plus, the larger screen on a tablet will be easier to work with while mobile. Developing for a single platform (iOS or Android) will cut your development and maintenance costs practically in half.

Here at Big Fish, we start every project with a Discovery and Design phase that includes the types of activities I mentioned above. We want this project to be a success just as much as you do and we have your back on making that happen!