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
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.
I diagrammed the categorisation of the information architecture related to account and user management.
And hypothetical user journey/flows.
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.
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.
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.
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.
Other customer support tickets were of basic functions regarding their own account: password and emailmanagment. Below are the prototypes I created for these.
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
Editing facility address at payment stage
Managing users (members) as an admin member
Requesting facility access as a member