Aggregate account settings
Project layers discussed below:
- Introduction and goals
- Quick fixes
- Mental model framing
- Design Refinement
- Online Help enhancements
Introduction and goals
An existing web-based account manager and online help manual was in use for the Aro (called Kiha at the time) beta users, which needed various enhancements in order to streamline the on-boarding process. I was asked to help make the interface friendlier and more suitable for a future Android/iOS version.
Beta users were already having many problems with the interface, so quick fixes were the first items to address. I assessed the current web app and proposed some simple changes.
First I started creating wireframes to communicate:
Then I found these were not the best way to collaborate on designs with the product manager and switched to annotated mockups:
There were no personas created for this or any other project at the company, so I wrote a set and shared them. As our beta user insight grew, I later found that two of the personas should be discounted for the time being—since they were not yet present in the user base.
These proposed recommendations were implemented while I considered improvements to the on-boarding and usage flows—taking the simple mapping below and adding functionality to handle more cases and respond better to user actions.
A company-wide re-theming effort was getting underway and that presented a good opportunity to accompany that with a functional redesign of the web interface. I created several versions based on the same principles of a single screen scope of interaction with more comprehensive messaging.
Mental model framing
One issue that came up from polling the beta users was that they were asking a fundamental question: Why am I at this web site? They were confused why they were sent there and why they were being asked to add their email accounts when they already had signed up for a Kiha/Aro account. I looked into the issue and found they were given nothing to simply explain what Aro essentially did. I created a graphic to help visualize the service and the problem went away.
Designs were chosen for incremental implementation and I turned flat designs into graphics assets (pre-css3 browsers needed to be supported at full visual fidelity) and style sheet definitions. I worked beside the developer to field any new design decisions that came up and shared graphics preparation with another design team member when we were asked to perform urgent tasks on other projects.
Immediately beyond this redesign I wanted to fuse the interface further with context sensitive help, improve the mental model, and re-use all page elements for the mobile web experience—since the current effort wasn't directly addressing the desktop/mobile divergence.
While I was happy with the mental model, there was another rebranding underway and the treatment could go in many directions—this being one I favor for smartphone, tablet, and desktop:
Online Help enhancements
The online help had been problematic in both maintenance and capability. This was having a direct impact on users' ability to inform themselves while using the web interface. Looking into the problems, I designed a new architecture to bolt Wordpress Content Management onto the existing Ruby-based display framework with its complex permissions system intact.
We imported the help contents into Wordpress and set up a back-end editing environment that allowed the Help writers to create, proof, and publish their documentation as soon as new releases of the web and mobile apps were pushed to production.