Custom Application User Engagement – Expectation vs. Reality
What do your end-users expect when they interact with your organizations application? How do you want them to react? We’ll examine the expectations and realities of custom application user engagement.
As consultants, the team and I are always mindful of various considerations pertaining to custom application user engagement – business requirements, statements of work, satisfying use-cases, being wary of edge cases, and the like. However, when everything is said and done, you likely won’t truly know how end-users are expecting the app to behave, or if they’ll even make proper use of it, until you put the app in their hands and observe.
In this observation, you might encounter various behaviors – the nods of approval, the smiles and laughs, or (as is often the case) the looks of frustration and bewilderment upon the faces of less tech-savvy users. Getting involved, gathering information, and observing your end-users’ interaction with your custom application is the key to arriving at effective and user-friendly solutions that simplify your business processes.
Often, custom applications are created to address an inefficiency or an operational gap within an organization. Below are two examples of custom applications that Smartbridge has developed:
KitchIntel – A solution accelerator that brings modern intelligence and automation to back-of-house food service establishments. This completely custom application streamlines the cooking and prep process for quick service restaurants (QSRs).
When designing an application with respect to well-defined business requirements, business processes, use-cases, and mockups (and while keeping with agile delivery practices), the expectation is to construct a product that delivers end-users the means to seamlessly bridge and eliminate gaps and inefficiencies.
Unfortunately, custom application user engagement is hardly ever straight-forward. Giving users the means to simplify their business processes doesn’t guarantee an application will hit its intended mark. A simple visit from the consultant to the client-site to observe the users interacting with the application will lead to very telling observations.
Even features that have gone through several iterations of testing, feedback and subsequent improvements almost immediately prove to be outright confusing, or even out of place for some of the users. Though your organization may have well-defined business processes which the application is configured to accept, observations will reveal there are everyday occasions in which even these well-defined rules don’t hold.
In the case of KitchIntel, what if the grill wasn’t quite up to the exact temperature? Or what if one grill operator took longer than another to place and remove items from the cooking surface? Further, how are we handling inconsistencies in weight and uniformity of certain pieces of food being placed on the cook surface? Similarly, as we trekked up ladders into ceilings and AC ducts with our clients at a field services company (in developing our field service mobile application), we observed how impractical an app with such small print was in meeting the field worker’s needs.
Taking notes of these observations is invaluable, and is paramount in producing a final product that has the desired effect on your organization. These observations not only reveal a wealth of useful information to those providing the service (i.e, we the consultants), but to client organizations as well.
Clients often put us in contact with individuals in their organization who have a lot of business knowledge (like project managers, for example), but may not always have the same level of day-to-day operational experience as our intended end-users. Therefore, client site observations made at the “ops” level can provide a more holistic view of the business processes the application is aimed at improving.
In the case of the applications mentioned above, some of these observations didn’t necessitate any changes to the code. Rather, a normalization of business practices to ensure end-users are performing their day-to-day operations efficiently, and in accordance with the defined business processes. Thus, allowing the application to seamlessly eliminate inefficiencies as originally intended, all the while improving operations within your organization. After all, we want you to do well so we can do well, right?
The Importance of Getting Involved
The importance of getting involved with your end-users and understanding how they will be interacting with your application should not be underestimated. It gives those providing the service a realistic view of the client organization, and the environment in which the service will be deployed. It’s extremely important to understand and include end-user adoption as a critical step in the project.
Remember that even the best design solution is no good if the users fail to accept it. Keeping this in mind early will lead to a solution that will more closely satisfy the intended use-cases, and generally be accepted at all levels of your organization.
Post Coming Soon: A Digital Toolbox for Everyone – Low Code vs. Custom Development
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!