Asana view only licenses

🤔 The project

Asana was introducing a new “view only” license that would allow organizations to share visibility into work without giving users edit access. Cheaper per user than a traditional enterprise license, view only licenses would allow billing owners to streamline their license management – a major cost-saving win for folks trying to keep spending in check. The launch would allow Asana to both help existing customers tighten their budgetary belts and bring in new clients who wanted a way to save money on licensing, all while helping more people work together effortlessly. 

We needed to communicate to IT administrators and users the pros and cons of a view only license as compared to a traditional enterprise license, and we needed to clarify the process of issuing or requesting and approving one.

📝 The task at hand

I was asked to craft an end-to-end content strategy that used clear, concise, consistent language to explain the new license type throughout the product.

The goals were to clearly communicate the benefits and limitations of the new license for users and organizations, to make the license request and approval process simple and to ensure consistency across in-product, support and marketing content.

👨‍💻 What I did

I collaborated with the lead product designer, Peter Tang, as well as UX researchers, product managers and engineers to gain full understanding of the new license and the users who would be affected. 

I worked through the many different end-to-end user flows that we needed to account for – members, collaborators and admins working in and out of product – to create a content framework that was straightforward and user-friendly.

I developed and refined language for the incredibly diverse set of touch points – toast notifications, tooltips, upgrade prompts, modals, data tables, emails and more – that related to license requests, approvals and denials. 

During the project, the scope increased to include a new CSV user import tool that allowed admins to import users and provision licenses in bulk. I worked with a separate UX designer, Nick Foster, to build out the user flow and define the language and messaging for that feature.

I also ensured that the language was user-tested, vetted by legal, documented for use in help articles and fully aligned with Asana’s established voice and tone.

The launch was smooth and incredibly successful, with strong enterprise adoption and minimal confusion from day one thanks in part to clear messaging that helped admins and users understand the license’s value and limits at a glance.

This meant more organizational collaboration with less spend for billing owners, and it meant more new clients and revenue for Asana. 🎯✅💰

You can’t always get what you want…

From the start, I didn’t like “view only” as a name for the new license and suggested that we use “viewer” for several reasons:

• The “only” implied restriction rather than capability as a collaborator
• It removed the focus on human-centered language that was a part of Asana’s voice
• It imbued a sense of “less than” in users assigned that license type
• “View only” didn’t align with existing permission terminology that used “viewer”
• There was an internal push to implement role-based access control (RBAC) – which would further enhance the importance of role-focused terminology – and I knew that using “viewer” could get us ahead of that move

So, I compiled my thoughts and brought them to the table, aaaannnnd my proposal was shot down. Not because my suggestion wasn’t sound, but because the first-to-market advantage is sometimes impossible to overcome. In this case, the marketing team had used “view only” before I joined the project and it had stuck. 😭👎

…but if you try sometimes

Knowing that we were moving forward with what I saw as a sub-optimal name, I figured out a way to make it better. Good teams I’ve been a part of follow the principle of disagree and commit so, as a good teammate, I committed. 

In the designs, in internal communication and in documentation, there was a lack of consistency in how people wrote the name of the new license; variations included View Only, View-only, View only, view-only and others. I wanted to fix that. 

I assembled examples of the various places the name would appear in the UI, researched internal naming conventions and protocols and talked with teammates to make a proposal to leadership: view only. No hyphen because the term was a name rather than a compound modifier. Sentence case because it wasn’t a trademarked term at Asana. That effort helped us come to a collaborative naming decision that worked better across the product. 😁👍