I started the process by writing user stories. The stories were based on earlier qualitative research I'd done to help me understand the user, someone who I knew was net new to the markets SAP tends to target.

The user stories informed user flows. Above is a snapshot of the flow for purchasing. I used these flows as a starting point for conversation with the development lead and other stakeholders.

Another example of a user flow where I've outlined all of the places where someone could learn where they're at during a trial period. This flow changed a lot based on what stakeholders in the customer experience team wanted to do in their marketing efforts.

Sometimes, user flows came up well after I thought I'd completed my designs. I made this sketch together with the developer to clarify what could happen in both trial and paid scenarios when an account expires. What does the user see if they try to login during a "grace period" and after their account no longer exists?

I introduced a new section in the main navigation, called "Account". Here, users could choose to buy (if they're on a trial) or upgrade in-app (if they're paying customers). 

I also suggested removing some administration functions such as deployment environments and connections because they didn't seem necessary given what I knew about the "low-touch" roles.

I also proposed renaming "Users" to "People" because in "low-touch" scenarios it seemed critical to make this UI friendlier and more accessible to users who may not be enterprise System Administrators. 

After discussions with stakeholders in development and customer experience, this is the final proposal for low-touch navigation compared to "high-touch" (or, enterprise-level accounts).

"Users" becomes "People", a place where low-touch and high-touch admins can manage users in their account. "Account" is for "low-touch" only: the in-app shopping experience. 

After user flows and IA changes are approved, the UI design for in-app payment can begin. In this example, a trial user can choose to purchase by accessing the "Account" view in the main navigation or by selecting "Buy" in the global toolbar.

The self-serve payment journey has begun. A user can see subscription cost and terms before they complete the check-out process.

This design was minimum scope for the initial release. In future, this view is the place where an account Admin can easily upgrade, change account details and ownership, get an overview of account usage or review invoices.

I'd also proposed redesigning the "Users" views to a friendlier design where it'd be easy for "low-touch" account administrators to add people, assign roles, and get an overview of how many "seats" are left in their subscription.

Cards group users by role. An Admin could select one or more people to either remove them, view details, or re-assign roles.

Editing and creating functions are at left. View functions are at right. A user can toggle quickly to see who is active and who isn't to help them make decisions when maintaining their account.

I designed alternate views such as this list view because it was important from a development standpoint to create a UI that could translate well to both "high-touch" accounts with thousands of users and "low-touch" accounts.