Product Design and Development

M2030 - Scaling up settings (B2B)

Scaling up settings

Enable the main account user/lead user to customise their account settings, meeting their user needs.

Responsibilities: UX/UI design, UX research, data analysis
Length: 2 months
Team: HoP, PMs, Customer Support, Engs.
Year: 2024

HMW allow for the lead user of the platform to do their JTBD in a safe and secure way?

As the other main projects were being developed, other major usability issues were being spoken of to myself and the PM as part of our user research.

There were also numerous customer support tickets that were based around the aspect of settings, data privacy and general management of their account.

As the platform had launched as an MVP focusing on the main features of the product, the general user management and settings needs had not been prioritised and were now becoming defunct

Discovery

A user survey, built within Appcues, asked and collected data as to what they intend to do within the platform/what their job responsibilities are.

2 months of results were thus:

There was also the fact that 758 organisations had not created facilities - this was later rectified by the sign-up and onboarding work.

Mixpanel analysis indicated that viewing (unique visitors) the member page, as well as the separate manage members had high traffic. Part of the user 'flow' was that users were clicking to manage licenses and change their language settings.

There were various problems that had been defined by customer support tickets and user feedback.

A main one that had greater effects on the user efficiently using the product, was assigning users to a 'facility' within an organisation aka an account. There could be 1 or many facilities per organisation, each having its own data and set of users accessing it and potentially not other faciltiies within the account due to no access/assignment being granted.

Therefore, I listed out the assumed problems with various viable solutions and the associated risks. This helped to scope and develop work.

Some of the user/account management work had not been deemed a priority with no business case, all work had to be done alongside prioritised work. I therefore focused on the main problem of user/facility assignment.

Define

I diagrammed the categorisation of the information architecture related to account and user management.

And hypothetical user journey/flows.

Design and Development

The user needs of user management and account management were intertwined. All of the following design were created as viable prototypes to show to users for testing ad stakeholders for feedback.

User management - assigning users to facilities

The current product functionality (below) allowed users to assign a user that they wished to invite, when they created a facility.
However both parts were skippable if necessary and there was no prompt or delcaration of why this was in the best interest of the organisation/user later on.

Part of this issue was making sure that the users were invited. Making this functionality more usable and prominent was key in unlocking the problem of assignment: having your colleagues on the platform is step 1 of the task of assigning them.

How user assignment could work at onboarding stage in much more detail than the current product user flow: so users
How user assignment could work at onboarding: making it a minimum ask as possible, by only asking there to be a 'lead user' required as part of facility creation
If the invites were rescinded, what messages would the invitee and invitor need to see?

Could the need of assigning users to each facility be made obvious via a wizard?

User management - showcasing whether they are invited, functionality to resend an invite and an option to make them a lead-user.

If they were unassigned, in the current product, this wasn't obvious: only a '-' instead of place names. Therefore I prototyped a version of making the table state with clarity, as well as giving the functionality.

I also prototyped the idea of allowing users (with member permissons only) to request assignment/access to a facility.

With the account creator/lead user(s) of the requested facility to receive the email request.

However, an email to multiple parties was not efficient or potentially scalable, so I prototyped the request via a notification system had been developed with another section of the platform for vital functionlity.

User management (self)

Other customer support tickets were of basic functions regarding their own account: password and emailmanagment. Below are the prototypes I created for these.

Facility management

Other user needs that I prototyped ideas for were deleting a facility and needing to edit the facility address at time of payment. Below are the prototype videos for these.

At this point in time, the product was being descoped in all areas and this is where my time with this work ended.

Editing the organisation's address

Managing facilities

Editing facility address at payment stage

Managing users (members) as an admin member

Requesting facility access as a member

All Recent Work