If you were tasked with designing a car, the first few requirements would obviously be that it start, that it go where the driver intends, and that it stop safely when it arrives. Your initial interfaces might include gas and brake pedals, a steering wheel and perhaps a shifter to control direction. Testers of your new device would immediately complain that it's difficult to drive while standing up. You add a seat. Notice a pattern?


01_Dilbert_requirements.png

Dilbert cartoons copyright: United Feature Syndicate Inc.


The more something is tested, the greater the revelations of what's required. The same applies to application design. It is therefore critical to involve testers, users and other stakeholders early in development, when it's easy to make changes. This should generally begin with the requirements phase.


Here's a look at some best practices for determining what's required of your application, and some requirements that should be on your list every time. 


REQUIREMENT ANALYSIS

The decision to create an app generally stems from a business need. For Zebra customers, that typically involves reading barcodes or RFID tags to register sales, manage inventory, or to track packages, pallets or patients.

 

Behind all apps are the Product Goals, which might include:

 

  • Collecting, storing and forwarding data
  • Actions or processing the data
  • Physical output such as an invoice or receipt
  • Additional actions by the user or customer such as swiping a card
  • Information displayed to the user or customer as on a kiosk


User Needs are equally important to the analysis, and the need of the app's intended users should be gathered during the pre-prototype stage. Aside from user-stated requirements, your apps always should include the following attributes:

  • Easily discoverable features and functions
  • An intuitive, efficient workflow that's easy to learn
  • Simple, non-destructive recovery from erroneous actions
  • Interruption handling; recoverability from long pauses in activity
  • Enjoyable, satisfying user experience that includes visual feedback


To build your app with easily discoverable features, present only the functionality that's required to reach the goal. Avoid splash screens that must be manually dismissed, and present all app functions using a single page design, but only if it's possible to do so without clutter. Refer to Touch Target Best Practices for guidance on the presentation layer.

 

02_Three_inventory_shots.png

These screens are part of Zebra's tutorial for building a simple inventory app.


An efficient workflow presents the minimum number of steps to get things done, particularly for the app's primary functions. That's one of the keys to a helping you build a satisfying user experience that's easy to remember and that enables workers quickly gain proficiency. Conversely, deleting records and other destructive or irreversible tasks should require at least two steps to complete and be located away from the app's main functions. This helps ensure that erroneous actions don't end in data loss.


Among the most overlooked attributes of an app is how it will respond after long periods of inactivity. If the user is unexpectedly called away from inventory tasks to help out at the register, for example, will your app timeout and cause records to be lost? It's important to design your app to recover gracefully from interruptions in workflow, which are inevitable in most line-of-business usage scenarios.


People should feel confident while using your software and never wonder whether a task has been left undone. Build screens that provide feedback on all activities. This gives the user a sense that the're in complete control of whatever they're doing. If multiple screens are necessary, all screen interfaces should work in basically the same way, and each should have a "Back" button.

 

03_Prototype.png

 

PROTOTYPING

With requirements close at hand, develop a prototype of your app that blocks out its basic workflow and present it to all stakeholders as soon as possible after the requirements meeting. The mock-up screens don't have to contain any underlying logic, but should be detailed enough to facilitate a discussion of the application's basic functions and flows. Incorporate suggested changes into the next version of your prototype and present them to the team once more.


Once you've gotten stakeholder buy-in, you can begin building your app putting logic behind the screens. Convene the team at each major milestone to demonstrate that development is on track and confirm that requirements have not changed.

 

04_Dilbert_requirements.gif

Dilbert cartoons copyright: United Feature Syndicate Inc.


Business and competitive pressures often can lead to changes in features or requirements of an app while it's still in development. Major features or minor, at some point the decision must be made to freeze an application's feature set and implement those changes in a future version. This decision usually varies by project and by company.


One way to fight feature creep is to adopt an MVP philosophy, that is to focus on creating a minimal viable product. Rather than trying to build an app that is all things to all users, narrow the focus to include the business goals and nothing more. Concentrate on doing one or two things extremely well, and leave the rest for an update or another project altogether.


SOURCES

SmarterPlanet: Oft-overlooked requirements

OpenRoad: Mobile-UI Design Best Practices
TechTarget: Defining Requirements
Appmethod Blog: Top 5 Best Practices for Mobile UI Design
Dilbert cartoons copyright: United Feature Syndicate Inc.