7

CX is not UX, but should it be? The misery of purchasing Figma Enterprise

 2 years ago
source link: https://uxplanet.org/cx-is-not-ux-but-should-it-be-the-misery-of-purchasing-figma-enterprise-67491fd3d3d0
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

CX is not UX, but should it be? The misery of purchasing Figma Enterprise

Typically, User Experience (UX) is what happens ~inside the product~. UX often does not extend to such interactions as customer acquisition (owned by marketing and sales), onboarding (account management), problem resolution (customer support), off-boarding, etc. Sometimes those topics are delegated to a vague discipline of Customer Experience (CX). But in reality, there is rarely a holistic approach to end-to-end experience, that combines both CX and UX.
An illustration representing frustration by @viniciusamano

A recent accident with Figma is a great example. As UX professionals, we love Figma UX. Actually, the plan was to write about how smooth the transition to Figma was. I didn’t anticipate it would be so easy to migrate an entire team of designers and a huge library of legacy assets from the old tool (Sketch) to Figma. Just think about it — it’s our bread and butter, a designer spends 80% of their working time in there, we can use it with our eyes closed. Imagine how hard could it be for a person to change their habits, but it was not with Figma. Until Figma messed us up royally.

Figma was so promising that our team made a bold decision and switch from a professional plan to an enterprise one. In fact, the enterprise plan barely has any advantages, at least doesn’t worth the price difference in my opinion, but a security team thinks otherwise. So we have got it because of the SSO, but having multiple team setups is a good bonus, although not a critical feature for a team of our size.

Nonetheless, let me describe our “Switching the plans Customer Journey” for you to judge. I admit, an ideal solution is far from obvious, but the design thinking method could help here.

We are a serious corporate organization (just went public *ironic smile*), so many instances are involved in the purchasing process: Design heads (initial decision-makers), Legal and Purchasing departments, and a small army of actual designers, product managers, developers, content writers that use the tool daily.

  1. It’s been a few months since we have been using the tool. Thus a professional plan is paid a year upfront. An enterprise has to be paid yearly.
  2. We apply for an enterprise plan and have a typical call with sales, where they explain all about Figma features (hey, we are already using Figma, we don’t need it to be sold to us again).
  3. They offer us a 14 days trial. We asked what happened after 14 days, and the answer was that they migrated us back to a professional plan. The problem is that the Professional plan only allows one team, but Enterprise can have multiple, so they need to be all merged, and it has to be done manually by ourselves. Alright, probably it doesn’t make sense to split our project into teams just for 14 days, does it? On the other hand, multi-teams setup is the primary reason we want to go Enterprise in the first place, so logically we should test them.
  4. In the meantime, we got approvals from some internal instances, but not all of them. We are a Public Fintech Company. Do you know what it means? Bureaucracy. We will get there eventually. The question is when the “last signature” is signed.
  5. In the meantime, the team is convinced we can move full speed with using Enterprise features and setting up the teams — we’ve got approval, right?
  6. Wrong. The trial was suspended at 11:37 PM without notice. That small army of designers, product managers, developers couldn’t access anything they needed for work for the entire day. Figma and we are in different time zones — California and Europe respectively. Until the end of the working day there was no response, we were blocked. It is called the interruption of business, how many people-hours have we wasted, can we Figma trust in future? Do we really entrust our precious innovative ideas to this company that stores them on their clouds and can just cut our access off in a single move? Is it not is safer to keep our files on our computers, like in good old times? I kept convincing myself that it’s not about Figma-the-whole-company; it’s a single salesperson mess up.
  7. An obvious question would be, why was the whole account suspended completely but not downgraded back to our paid a year upfront Professional plan? It turned out the professional plan was refunded, so we would have to go and manually pay it again. Remember what paying means in a Public Fintech Company? Time.
  8. After many emails, we have extended our trial for a little longer, but eventually, we need to merge our files into one team, just to be split again in a couple of weeks. More frustration and time wasted. The story is not over.

It’s hard to criticize Figma, they don’t have to offer us free trials to compensate for our slow processes, but on the other hand — what benefit did we actually get from it that would be worth the wasted time? What is clear, that they offer self-service model service to enterprise customers without understanding their customer situation. I guess it’s possible to get approval for a critical software purchase in less than 14 days, but our example shows it’s not a general practice. Would it be an acceptable solution to suspend an actively used service at midnight for the entire organization?

Could there be a solution that would lead to a better experience for a customer and not as an expense of a service provider? I bet there would! For example, we could use a Trial not free, but on top of our Professional plan that’s already paid, and when ended, just smoothly downgrade back without making our team spend time manually merging teams. Maybe they could allow us to pay monthly before the long-term agreement is signed. Or they could calculate the time before signing the contract into that contract (I’m not sure if it’s legal, but you’ve got the point).

In UX, we research, test, and iterate on similar problems to find optimal solutions. But the experiences outside of a product are often outside of our hands. I use the example of customer support experience we used it has (and shame on me, it didn’t change much because it’s not a part of the product).

It goes like that:

  1. when our user needs a feature X while using the product, she should click a support link ->
  2. which will lead to a FAQ page,
  3. from there she would navigate to a support form,
  4. in the form, she would have to fill up all information about herself, contact details, her company, and eventually, her problem, hit “Submit” and ..
  5. ..prey she would get an email response within a reasonable time.

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK