Are you a Power Platform person? Are you building cool things with PowerApps, Flow and Power BI? Cool!

One thing that Power Platform, especially PowerApps does is it allows us to literally build cool things. Yes, cool. Cool because PowerApps has the ability to provide solutions for practically everyone – be it a sales person, a technician, inspector, teacher, construction worker – the list goes on. The scenarios these folks are involved in are almost always very interesting. It involves being out and about, doing various things. A sales person wants to be able to access information quickly before they go see a client, enter notes quickly after their meetings, and update some important information with minimal clicks. An inspector or a technician may want driving directions to their customers’ locations, have the ability to communicate with them with minimal clicks, and take many “before and after” photos to document their jobs. If any of these folks are driving to meet their customers, it is also very likely that they would want to take the shortest route possible so they don’t spend too much time driving.

Of course, we can build everything that they desire very easily. The beauty of Power Platform is that it can really make everything possible. When we build apps for our audience, we test it out, get feedback, make minor tweaks, and deploy. Right?

Coming From Dynamics 365 (Or Any Other Platform, Really)

If you are from the Dynamics 365 realm, traditionally,  for the most part, you are building apps for the back office folks. You may argue that no, we build CE apps for the front line, field workers too. If that’s your argument, ask yourself how many of the implementations where you forced field users to use the Dynamics 365 mobile app were successful. There is general consensus around how well the app works for field users, and the consensus is not in favor of the app!

Model driven apps in general are not geared towards mobile users. They simplify a lot of complex business cases and improve visibility into lots of tiny little data points that are distant and detached. They rely on building blocks that are geared towards behind the scenes processing and automation. The UI can get really busy, and in order to get the full picture or even take an action, it requires the user to really be comfortable with the limited experience the UI provides.

Moreover, model driven apps are limited in what they can do because by default they are only functioning in the Dynamics bubble. What if the photos that your end users are taking need to go to a very specific SharePoint folder or list? They want to be able to see charts from their existing Power BI reports in their mobile phones. Now what do we do?

There was a time when the Dynamics 365 app/ model driven apps were our only mobile solution. (our hands were tied!) If you still expect your customers to use model driven apps in the field, please rethink that thought process, especially with the advent of Canvas apps.

Building & Testing PowerApps Is Different

Here’s the thing – when we build apps, we follow all sorts of processes to document requirements, build functionality, fix bugs, and accomplish milestones. Azure DevOps is a favorite solution when it comes to tracking where we are and how much progress we have made in our app building process. Especially when it comes to testing, we can still rely on the tried and tested ways of testing and fixing bugs. However, there is just something different when it comes to testing Canvas apps.

Remember, we are building interesting apps for interesting use cases. Your app is most likely not being used on computers but on mobile phones and tablets. When it comes to testing your app, besides doing the regular (dare I say, mundane) set of testing activities, why not go the extra mile just a bit? Since the app will be used by users out in the “field”, why not test it out in the field too? Of course, there are several caveats here, in that you should have easy access to the location where the app will be used, and you will possibly need permission from the right people to try it out “in the wild” but assuming you can get to the location easily, and folks on the customer side are okay with it, testing it in the real world is very eye opening. Not only do you get a real sense of how exactly the users will use the app, you will also understand the flow in which tasks are done.

Consider an inspection app, for example. When you gather your requirements, you may be told that users drive to a certain location. Once there, they are expected to perform certain tasks and take many photos. It’s okay if this task is not done in a certain order but everything must be completed. The photos can be either taken directly from the camera in the PowerApp or uploaded from the phone’s image library.

Let’s take a step back for a second. One would think that because the PowerApps camera control makes taking and uploading photos so easy (one click!), why would anyone want to upload photos from their photo library?

There could be a few reasons. One, it is possible that where they are – whether a factory, a building, gas station – they may not have good lighting. Because of that (and perhaps various other reasons), they may have to zoom in on an object. Can we zoom in on something using the camera control in PowerApps? No. Can we use the phone camera’s flash with the camera control. No? In those instances, it becomes important to give users the ability to use their phone’s native camera and upload the photos to the app.

In the field, users constantly have to deal with surprises. Things are not always favorable, because of which they have to make adjustments and find alternatives to get the job done. To make our users successful, we have to provide them with all sorts of alternatives. And what’s the best way to test out all the features we are adding for them and make sure all options really work?

By putting ourselves in their shoes.

Whenever possible, go out in the field, try out the app and see what it feels like to use it. Don’t just test it on your computer, don’t just run another test script to test the features, but get a real feel of it. If you feel good about using it out in the wild, chances are your users will be comfortable to some extent too. You will most likely still have to fix bugs and address limitations because those who do this job daily can spot missing features or bring up issues easily. But trying it out in a dingy gas station yourself will tell you first hand what the users’ experience will be like.

Why Do this?

It’s a fun yet very effective way of testing out an app in the real world. You can turn a pretty mundane “project” into an adventure. It’s different. It keeps the team motivated.

It’s all of the above.

Bringing it all together

Ultimately, we want our users to be successful and not get frustrated by lack of features. One way to alleviate pain points for our users is by testing the app in real life scenarios while also having fun! So go the extra mile, and really strive to make your users successful!

PS: A photo from that one time we went to a gas station to test an app!