Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

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!

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?

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

I had a similar issue just yesterday - my app can produce xls files with links back to the app. However, if the stars don't align correctly when user clicks the link, the browser won't send user's cookies so they are always just shown the login screen. You can implement a server workaround to refresh="0" and when the refresh happens cookies are sent again

https://stackoverflow.com/questions/2653626/why-are-cookies-...

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.

Well if it helps, sentry is incredibly easy to implement on a basic level, and the free tier is more than enough to play around with for quite a while before you need to step up to something more.

For us the process started with just including the script and getting a few crashes or exceptions here and there, and once most of us were comfortable that some time investment here would pay off, we really wired it in and the benefits just skyrocketed.

Now we even have it running on our server side code in one case because it's just such a damn good tool.

I will say that the downsides are that the search is fairly poor unless you self host and have access to the database, and forget about using it for any kind of reporting over time periods (it's actually really hard to see things like "number of times this error happened in the last week").

But overall it's a very easy system to layer on top of just about anything. I know nothing about your company or product, but see if you can get the approval to spend an hour or 2 to just try it out. As long as you don't have any PII its a pretty risk-free thing to try.

Brilliant. Thank you for this response.

Please tell me you are evaluating saas tools like zendesk and intercom. Depending on your app and your user sophistication, these can be great solutions. (If your username is expecting code examples, I'd look elsewhere.)

They have startup pricing and we've used both. It wasn't great to pay a monthly fee, but it was far cheaper than anything I could have put together myself.

Reply on news.ycombinator.com