While working on several projects over the past few years, my primary focus was a large customer-facing product that encompassed four distinct apps--two of which had mobile sides.
The three projects that I've included here are small pieces of this much larger puzzle.
All UX projects begin with research and engaging stakeholders. I try to understand the scope of the project, the level of effort and the ask before creating workflows or wireframes.
- Stakeholder meetings
- Digital mock-ups
One component of this large scale project was to assess user settings. This was a small but mportant. The software was developed in 2001 and the UI reflected this antiquated approach. After talking with internal and external users, I found that the user settings were confusing and redundant. I set out to understand what users wanted to be able to access in settings, and how things like permissions and multi-account access might affect user needs.
I created an evaluation and recommendations document to visualize and describe my findings.
The workflow illustrated how average users and users with multiple account access should be able to log in and out. My findings ended up increasing the scope of the project and expanding the level of effort because we realized the system used to determine account hierarchy needed to be updated.
The final product consisted of two versions; the version that we could release early and the version that utilized a new hierarchy system.
Evaluation and UX recommendations
Evaluation and UX recommendations
One of the issues the company faced was a lack of useful feedback from the existing feedback form. I reached out to different departments, including customer care, internal tools, and users, to better understand the scope of the problem.
I found that the current feedback form was hard to find in the existing UI andoverwhelming for users to fill out. There was also a level of distrust on the user's side, some users assumed that no one looked at the feedback forms. On the customer care side, I discovered that there was no way of organizing the feedback that came in, making it overwhelming for them to get back to users.
My solution was to create a concise form with no more than four input boxes, and to force the user to indicate the nature of their feedback. I also changed the location of the form link from the home page to the footer, so it was always available.
The workflow showed how the feedback would be captured on the back-end and how the system would sort the feedback based on the user's indicated needs.
The final product was smoothed out by the UI team and incorporated our new pattern library designs,
The existing software required users to log in using three inputs; username, password, and account number. While doing contextual inquire during the site reconstruction I found that users wanted to be able to log in using only a username and password. This was particularly true for users who needed to access multiple accounts; basically they wanted to log in quickly and view any and all accounts without logging out.
I met with the developers and project managers for this project and scoped out the level of effort before doing any wireframes. My aim was to understand how the data system would work and design around it.
Because users tend to have established expectations for password help the workflow, was fairly straight forward , but understanding the data structure and making sure it could be supported represented the 'meat and potatos' of this project.
Password Help workflow