Not in Control: A tale of UX Gone Wrong

This is what it feels like to use an app with poor UX

Poor UX can be the bane of a system. Even if your UI is polished and fashionable. Even if your internals are working as intended, subtle issues can burn your app.

To illustrate this, I’ll tell you about my story with one such app.

Who are they?

Control has a simple premise, give us access to your Stripe account and we’ll chart the monthly recurring revenue (MRR) of your business, and give you an easy to use interface to peruse your charges on desktop and mobile.

The company opened to much fanfare about 2 years ago, and was backed by Stripe via a loan/grant/investment of around $50,000.

They’re not a brand new startup; they’re not a total unknown so this is why I’m most surprised that after years they still haven’t gotten their act together.

Why them?

I was one of the first to join Control. I was a member in their beta program, and was as such inclined to be especially forgiving to any mistakes made along the way. I understand — I’m a developer myself — bugs happen and what matters is how you deal with them. Their support is great, their design is minimal and lovely to look at, but their UX…. their UX is terrible.

Barriers to Entry: Passwords

Their password interface is hilariously broken UX. The interface checks with client side javascript if your password matches up with their schema: 1 capital letter, 8 character minimum, 1 lower case letter at least. If you don’t type in password that matches, then it does not let you click the sign in button! It doesn’t give a validation error (even now, 3 months after I reported the issue), it simply looks broken leading you to wonder if its a browser bug or something else.

Why even let a user create passwords that won’t work during sign up?

Dead on Arrival

MRR calculations simply did not chart on the web app.

I had a complete and total blank screen, because the import process didn’t let it take into account revenue from when you joined Control.

The data is in the system, but it is not being included in the MRR calculation. Most of our business payments come from recurring revenue, but Control claimed the MRR was only $234.74 — a figure off by many orders of magnitude. By default, Control only counted customers & charges made after your initial sign up. Luckily, I earned something within the hour after sign up, or else I’d have seen a big fat $0.

I contacted support, they helped out with a special script to count previous revenue. This should be done by default (and maybe even is now), but that Control seemed to assume that my business started with them… is a bit presumptuous and could only be called a bug.

I’m a bit harder on them here, because this is a mix of a math bug and a UX bug. I’m very hard on math bugs since there’s a correct and definite incorrect.

Great Support

But it doesn’t save the day…

Months later, I notice MRR is jumping every ten minutes.

Screen Shot 2016–10–03 at 7.24.31 PM : MMR is $17,000+. I contact support.

Screen Shot 2016–10–03 at 7.32.50 PM. MMR is $8,559.49. I am still talking to support about simply canceling. They’re debating my understanding of MRR.

Screen Shot 2016–10–03 at 7.39.17 PM. MRR is $6,150.09. Support is currently claiming that data is being fetched in real time thus that’s why things are jumping about. I point out that I have only had 1 subscription for $20 in the past 10 minutes, it wouldn’t push MRR by thousands in both directions.

Now we’re still on support for the next 2 hours, patiently looking over calculation after calculation (aside: human support is a great thing, even in crisis), and finally we figure out that:

(a) no Control is not real time

(b) calculations for a particular time period are only kicked off if you look at that time period. So if you don’t log in regularly, the calculations will never be performed correctly and cached as incorrect.

This is a bug.

Engineer hat on: this is also a valid way to set up your system, saving it from handling calculations no one will care about.

UX hat on: without giving an indication that the calculation for a given time period is incomplete, you’ll have people working on bad data. Worse for a financial app, you’ll have people basing their business decisions on bad data… data that you provided to them in full knowledge it was incomplete without telling them so.

Worse yet, since the calculation is ongoing… the next time that someone looks at the report, the inconsistency will be gone! Which leads to people questioning others competence (and in my case, my own sanity).

If you love something set it free…

At this point, I’ve had enough. MRR is their core value-prop. If they can’t do this admittedly simple math, then I have no use of them. Alas, I cannot find a cancellation button.

I contact support with my issues, to request a cancellation.

I have to request a cancellation because they do not let you simply cancel your account. You have to beg for it. They spin this as a way to keep people from leaving unsatisfied due to solvable bugs, but at this point it irks me that I can’t simply leave without being forced to ask someone.

Errata

I couldn’t fit this into the main story, but here are other points where the UX failed.

1. Lots of features are not available on the desktop app (e.g. cohort analysis). This isn’t listed anywhere, and you’ll have to just find out for yourself. Apparently they’re mobile first to an extreme degree.
2. In their app, the churn calculations are all done via the logo method. This means you are counting the # of customers who leave. This is an odd fit for an app focused on monthly-recurring-revenue. Revenue churn which counts the # of dollars that leave would be a better fit.
3. The churn type used is only listed in a knowledge base app, 3 pages deep.
4. LTV is over the entire history of the account, there’s no way to get it to scope to a specified time range, so if you have a terrible 1st year, it can twist your entire calculation even if the other 9 years of your company were great.
5. The approval rate is similarly calculated across the history of the account. One customer who attempted 65 times to charge a declined card dropped our approval rate by multiple points. It’s not reflective of reality; we should be able to exclude outliers.
6. No way to find total sales per year, week, month, quarter. The charting only shows MRR.

Now I’m no longer using Control, and I’d urge everyone to avoid it if they can. Is their math wrong? I don’t know… I can’t know without doing it all myself, but it seems iffy since calculations are incomplete.

I do know their UX is poor, and poor UX can sink any ship.