How to Design Software People Actually Want to Use

Big Fish > Advice for Buyers  > How to Design Software People Actually Want to Use

How to Design Software People Actually Want to Use

How to Design Software that People Actually Want to Use

When executives get together and make decisions about how their software should be, focus often drifts away from the actual end user.  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 design you could end up with:

  • Features that no one uses
  • Exponentially more time needed for training and support
  • Low adoption rates, or adoption by force rather than enthusiasm
  • Unhappy users (employees, customers, etc.)
  • Mistakes, or incomplete information, entered by users of the app

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

Designing software people want to use, requires a commitment to involve your end users in the process.Click To Tweet

It means that 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 a manager at a company with a large field team that works outdoors surveying construction sites. Your field team currently writes 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:

  • Staff needed to type hand-written notes into a digital database
  • Difficulty reading someone else’s hand-writing
  • Paper forms getting lost
  • Lack of real-time communication between the field and home office

So, the decision is made to create an app that the field team can use to enter all this information and upload it instantly to your cloud-based servers. Developers are hired and given the feature list (i.e. list of forms and form fields required).

The application is built, and the field team is 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 galore.

Some pretty simple actions could have prevented this.

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

Had your project team involved actual users in the design process they would have learned a lot! Through activities such as job shadowing, conversations, 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: touching small buttons and manually typing a lot of information on their smartphones will be difficult.
  • 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 points you initially planned for every form will be removed and auto-filled instead.
  • The app will have large buttons so they are easy to touch
  • 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 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!


 

We Develop Custom Mobile Applications

Looking for a team to design or develop your mobile application?