iKno Intranet Subscription

A subscription-based intranet for organizations with 100-200 employees. The price is based on the number of users who have been given access to the intranet.

Each organization has an administrator user responsible for managing user access as well as payment.

We were faced with a choice, are changes to the number of users automatically reflected in the price an organization pays—offering, perhaps, a simpler experience—or do you ask users to first select a tier and then manually manage users? Due to development budgetary limitations, we went with the latter.

Roles:

Process

I began by thinking through the user flows at the highest possible level, visible in the first column. Following that I organized my thinking around the basic task—selecting a plan, entering payment information and submitting the payment. I then started blocking out the general layout of the page and then moved into thinking about how user-generated content, microcopy and calls to action were situated in each of the blocks.

Sketches

First Time Signup User Flow

Adding More Users/Upgrading Plan User Flow

Follow Up Payment (non-Autorenew) User Flow

Payment User Flow

Layout Blocks C & D

Account Overview Stacked - Detail

Users & Plan - Detail

Payment Information - Detail B

Update/Change Payment Info User Flow

Layout Blocks A & B

Account Overview - Stacked

Payment History

Payment Information - Detail A

Prototyping

Once I had enough of the concept in mind from sketching, I began mocking up the experience in Axure. I began with Users & Plan and Payment situated next to each other horizontally. I had some concerns around usability and switched to a vertically stacked approach. I also removed the link showing the number of current users in the Users & Plan panel to simplify the transaction and keep the user focused on selecting the plan.

My initial thinking for the transaction experience—a horizontally oriented layout where users would first manage how many employees are given access to the plan and the price would dynamically update.

Since we needed to simplify for the development budget and the client wanted to move to tiered pricing structure, I changed the layout to a stacked approach. Users first select their tier and then pay for their subscription.

The Final Prototype

The UX process helped the client think through their pricing model. Originally they wanted to charge per user. But the user experience proved too difficult and confusing specifically around how payment would be submitted each time a user was added or removed.

I began this process thinking the user's primary task would be to add and remove users which would automatically update the price and the tier they could buy for their organization. However, after talking with the developer and given the development budget, we changed the primary user task to selecting a tier and managing users within the number available to them. It shifts the burden from the technology to the user, but we had little choice while minimally sacrificing the user experience.