You had a great idea how to help your coworkers optimize their work. You’ve built an app and deployed it in a production server. Now you wait for some signs of success: your happy colleagues praising the app or recommending it to others. But the messages of praise don’t come. You check the usage statistics and it turns out that no one is using it. Or worse yet, users open it once, only to never return. Adoption of your Shiny app has failed, but it’s not over yet.

Don’t throw in your app-building-hat just yet. Check the list below of what might be going wrong and how to deal with it. You worked hard on your app, make sure it’s a success. 

Here’s a few reasons why no one is using your Shiny app:

Users Don’t Know Your Shiny App Exists

Sounds trivial, but it’s actually more common than you think. Even if there was communication around the launch of the app, your users may have simply missed it.

If your users are local (i.e. on your team) this is easy to verify. It’s time to survey coworkers that you expect to be the users with one simple question: Do you know about [Greatest Shiny App Ever]?

If your users are the general public, you may need to create a marketing campaign around the project. To get the word out, try creating social posts, record video tutorials, or present at places like ShinyConf and posit::conf.

Users Know of the App, But Don’t Know Its Purpose

Potential users need to be informed about the app and be aware of its potential benefits. This is particularly important in large companies where thousands of different applications and dashboards exist.

It’s easy to overlook new solutions that aren’t immediately clear. To effectively communicate the app’s value (via emails, intranet, repositories, showcases, or training sessions), it’s essential to clearly articulate the problems it solves and who can benefit from using it.

Users Don’t Need Your Shiny App

Or, in other words, the users do not have a problem that the app is trying to solve.

This is a serious issue as it often indicates that the initial assumptions on which the app was developed were incorrect. But does this mean that the only solution is to abandon the app, archive it, and chalk it up as a loss? Not necessarily.

In many cases, the actual needs and problems may not be far off. By spending time with the users, empathizing with them, and carefully listening, we can discover how to modify the app to solve the real problem.

Of course, a much better approach is to identify and understand the real problems and needs before starting the development process. Then, by testing the solution with users, gathering feedback, and making adjustments along the way, we can ensure that the app addresses their needs effectively.

We have a wonderful video presentation on how to do just that by Maria Grycuk, Project Manager, on how to conduct effective user tests.

Users Can’t Use the App When They Need It

This is another significant problem that indicates the omission of an essential aspect of the problem.

For instance, the app may require internet access, but users may need the app in areas with no internet connection. Maybe the app is a web application that is not optimized for mobile screen sizes, but users need it while on the move, navigating around the city.

In such cases, it is crucial to identify the reason behind the issue and fix it if possible.

Users Simply Can’t Use the Shiny App

This is a common issue – users recognize the benefits of using the app and are eager to try it, but when they open it, they don’t even know where to begin. The initial thought might be to train them, or worse, to create a manual. While training sessions and manuals are important, they may not be the best solution – certaintly not when Shiny apps can be designed to be intuitive and so easy to use.

So, what can we do instead? We need to take a closer look at the user experience within the app. Is it intuitive? How does the user know which action to take first? Is the flow of the app logical? Sometimes even minor changes, such as adding proper labels or highlighting essential actions, can make a significant difference.

If you’re not sure where to begin when designing proper UX for Shiny apps, start with my 7 Steps to Designing Dashboards People Will Love.

Users Can’t Fully Solve Their Problem With the App

This often occurs when the app is built for one person, such as a manager, who has an intuition for what the team needs, but will not be the actual user of the app. Alternatively, the app may be intended for use by multiple teams, but only members of one team are involved in its development. As a result, the app may be overly tailored to the needs of one team and not suitable for others.

The steps to address this issue are similar to those when “users don’t need the app.” Once again, during development, it is essential to include as diverse a user group as possible to regularly check that the app is moving in the right direction.

Users Can Solve Their Problem In an Easier Way

If the app is intended to save users time but, due to a complicated interface or long loading time, it takes longer to solve the problem than it did before the app existed, users will naturally stick to their previous habits. This may also be observed if users open the app to download data, just to switch to Excel or Google Sheets instead of using the app itself.

If this happens, it means that during the discovery phase, the current solution to the problem was not recognized or taken into account. Therefore, the solution is to check which features of the current solution are missing. However, be cautious – if the interface is already complex, adding new features may not be the best option. Instead, refining and simplifying the existing features or even removing some of them may make the most important features easier to use.

Of course, you can check out Jakub Sobolewski’s Definitive Guide on Speeding Up R Shiny if performance is your issue.

Users Don’t Trust the App

This is a very serious situation that usually is a result of some serious bugs that users were exposed to. For example if the app was showing incorrect data and some decisions were made based on it – next time, the users will likely search for a different source of information, even if that will require additional effort. 

In such a case, the change shouldn’t be done step by step. It’s better to take down the app, fix all the major issues. Implement a solid quality assurance process, including automated data validations, software testing and User Acceptance Testing. Then relaunch the app, showing the users how the app development process was improved.

Users Are Afraid of Changes

Last, but not least, people don’t like change. If users are accustomed to the current solution, they may be hesitant to try a new tool. This often requires learning new skills and additional time, but most importantly, the effort to overcome the fear of “what if I do something wrong?”

In contrast to “users don’t know how to use the app,” this is a perfect reason for training sessions and detailed manuals. It’s also a good idea to encourage users to test the app and let you know if there is any confusion, explaining that it is probably due to the app’s lack of user-friendliness, not the users’ lack of knowledge. If users are accustomed to a certain UI/UX, you can try implementing those in Shiny (like Fluent UI or Blueprint UI).

There is also a technical aspect to low adoption, such as users not having access to the app and not being able to log in or a monitoring tool having a bug and failing to report all the sessions. These issues are usually easy to solve, but they should not be neglected. You can also customize your login pages to make the users more comfortable, or emphasize authentication with Posit ConnectCodeProject.

The post appeared first on appsilon.com/blog/.