3 ms·

Another point I didn't see mentioned was "support and documentation" (not necessarily SaaS specific, but still applicable) I was the lead developer of a greenf

Another point I didn't see mentioned was "support and documentation" (not necessarily SaaS specific, but still applicable) I was the lead developer of a greenfield new b2b web application that took several months to develop the MVP for, then another almost 2 years to develop support tooling and systems for. We would get calls that it didn't work with no other information, calls that it didn't work with "my older samsung", emails with pictures taken with another phone of the login screen with no other information, users that didn't know the name of the company they worked for, or even their username in the application. We found suprisingly that there was a subset of our users that couldn't even tell you if they were on iOS or android! But quickly we learned that it's not their job to care about that, it's ours. We spent the next almost 2 years writing in debugging code, shipping logs back to our servers, writing code to send errors back to us to avoid having to ask the user on the phone to "please read out exactly what the error message says" only to find out that it happened to them last week and they don't remember... We wrote code to be able to "playback" what a user is doing in the app before they have a problem so we could identify UX issues, and redesigned UIs to include important information so when users sent us screenshots or pictures of the device we could get useful information from it from anywhere in the app (like app version, os version, username, company, etc...). We wrote documentation for how to enable camera permissions that they may have inadvertently denied for several android versions and flavors and iOS versions because we found that some users would be confused if the images and names were slightly different. If you asked me today what makes our app better than all of our competitors, i'll tell you that it's hands down the "support" capability of the application, and that if a user has a problem, we can track down what they were doing when it happened and figure out a fix (either procedural or technical) sometimes before they even call the problem in! Also, it's a sure fire way to deflate the ego of the hotshot lead developer that thinks he's made the best thing since sliced bread when the most important part of the application is a glorified log shipper!

jamesvandyne 9y ago
Spot on. That's something that's next on my roadmap: building out a help and documentation site/portal. There is so much more that goes into building and launching a SaaS app than just the app itself. I'd to love to hear more about how you identified UX issues from pure logging data. Do y'all write anything up about this online anywhere?
- Klathmon 9y ago
  No, we haven't really written anything up. I've always wanted to start writing about stuff like this, but never get the time (because I spend it all writing stupidly long comments on websites like this!) But one example of how we use logging info to clean up our UX was just kind of "watching" what the users were doing by just following absurd amounts of logging (logs like "clicked x button" are short and cheap, as long as you can filter them out when needed, they are immensely valuable). Our application does a lot of barcode scanning, and we noticed just from browsing around individual paths in our log-shipping system that if some users had an error with the camera (lowend android cameras are a lot buggier than i would have imagined!), they would go into the settings, select the option to change the scanner to a wireless laser attachment, then change it back to the camera version before going back to what they were doing. Overall the process took them a good 15-20 seconds, and when they should be scanning about 1 carton a second in the app, that added up in both time wasted and in user frustration. We added a "retry" button to the error screen, and instantly the long workaround stopped happening. Then we took it a step further and would attempt to re-grab the camera in the background before showing the error to the users, which cut down on the number of those dialogs significantly. It was a matter of getting an alert that this "camera not readable" error was happening commonly enough to trigger an alert, and from there was about 10 minutes of browsing the "breadcrumbs" for a few users to see the pattern, maybe an hour of adding the "retry" button in the dialog box (and testing), and another hour to do the auto-retry a few days later. 3 hours of work when it's all said and done (of course, after the timesink of developing it all), and the product is better off. And that's something that i'm almost 100% confident that we would have never found out about without this kind of logging and reporting. We use sentry.io [0] for a lot of this error logging, and we have found it incredible at being able to "walk in the user's shoes" for things like this. [0] https://sentry.io https://sentry.io
  - gm-conspiracy 9y ago
    I really appreciate your comment. I have been pushing hard for our team to implement sentry. I have implemented JS logging for all of our AJAX interactions, but having sentry 'coalesce' everything into a single view, as you know, is immensely useful and actionable.

jamesvandyne 9y ago

Spot on. That's something that's next on my roadmap: building out a help and documentation site/portal. There is so much more that goes into building and launching a SaaS app than just the app itself. I'd to love to hear more about how you identified UX issues from pure logging data. Do y'all write anything up about this online anywhere?

Klathmon 9y ago
No, we haven't really written anything up. I've always wanted to start writing about stuff like this, but never get the time (because I spend it all writing stupidly long comments on websites like this!) But one example of how we use logging info to clean up our UX was just kind of "watching" what the users were doing by just following absurd amounts of logging (logs like "clicked x button" are short and cheap, as long as you can filter them out when needed, they are immensely valuable). Our application does a lot of barcode scanning, and we noticed just from browsing around individual paths in our log-shipping system that if some users had an error with the camera (lowend android cameras are a lot buggier than i would have imagined!), they would go into the settings, select the option to change the scanner to a wireless laser attachment, then change it back to the camera version before going back to what they were doing. Overall the process took them a good 15-20 seconds, and when they should be scanning about 1 carton a second in the app, that added up in both time wasted and in user frustration. We added a "retry" button to the error screen, and instantly the long workaround stopped happening. Then we took it a step further and would attempt to re-grab the camera in the background before showing the error to the users, which cut down on the number of those dialogs significantly. It was a matter of getting an alert that this "camera not readable" error was happening commonly enough to trigger an alert, and from there was about 10 minutes of browsing the "breadcrumbs" for a few users to see the pattern, maybe an hour of adding the "retry" button in the dialog box (and testing), and another hour to do the auto-retry a few days later. 3 hours of work when it's all said and done (of course, after the timesink of developing it all), and the product is better off. And that's something that i'm almost 100% confident that we would have never found out about without this kind of logging and reporting. We use sentry.io [0] for a lot of this error logging, and we have found it incredible at being able to "walk in the user's shoes" for things like this. [0] https://sentry.io https://sentry.io
- gm-conspiracy 9y ago
  I really appreciate your comment. I have been pushing hard for our team to implement sentry. I have implemented JS logging for all of our AJAX interactions, but having sentry 'coalesce' everything into a single view, as you know, is immensely useful and actionable.