Wells Fargo's Time Tracker
I was hired as a contractor to work on a three month project for Wells Fargo in Winston-Salem, NC. The project was within the HR software division of the company and was to better the current time tracking system.
Due to NDA I cannot include exact images or detailed information, especially any that may reveal trade secrets. This is a representation of the work completed.
For many years the time tracking system had been a pain point for employees of Wells Fargo. The system was tedious to use and required a lot of time for employees to input their information. Wells Fargo felt it was time to better configure the system to meet employees needs as well as letting the system become accessible.
Main problems that needed to be addressed:
*Managers ability to have a high level view of employees time and time off
*Manager’s delegation of responsibility when on a leave
*Seeing PTO available in a clear way
I was lead on the design team and worked with FTE in research, product management, development, and leadership. I reported directly to the UX manager of HR software who was responsible for several projects.
#The Current System
The time tracking software was a 3rd party application that Wells Fargo bought the source code to instead of having the vendor maintain. No changes had been made to the UI and it has been at the default interface since launch. Little had been done to maintain it.
We had a short time to design the system so we had to plan smart and work effectively. Upon on-boarding we meet with key members of the team to discuss the current system and the plan going forward.
The overall goals of the project were:
*Decrease manager time needed on time off requests
*Decrease non-exempt employees time spent completing timesheets
*Increase communication between employee and manager
*Increase managers power in delegating time off
The development team was working on separating the UI from the backend so they were no longer tied together. They were creating APIs that would allow the new frontend to talk with the backend. This would free up the coupling and allow flexibility on this project and the future when further improvements would need to be made.
The tech team also decided to use a Wells Fargo owned framework for the frontend called WFRIA. The framework contained the needed branding, AAA accessibility standards, and HTML elements to make the project speedier and fit within the Wells Fargo ecosystem.
As the main point on the project it was my responsibility to develop the plan for how we would best accomplish our goal. I worked with my team to generate an outline of our plan in phases, explained in subsections below, with goals for each section.
I then met and planned with researchers and content strategist separately to identify in each phase what they needed to accomplish for their parts of the work.
The discovery phase was divided up into three parts for each role on the UX team.
I was responsible for creating a interaction catalog by reviewing the system page by page marking interactions used, form elements, role visibility, and accessibility challenges. This was documented in a spreadsheet that could be sorted for easy reading of information.
The researchers developed an interview guide based on requirements and information we mutually agreed upon in planning. They then executed interviews with different Wells Fargo employees focusing on the role types.
We opted to not use personas as we felt the roles based approach fit best and the employees in those categories widely vary in bank sections, technology experience, and daily tasks. However, each role had the same tasks to perform in the time tracking system.
Our content strategist also went through the system keeping track of content on each page such as instructions, labels, imagery, videos, and more. This was kept in a spreadsheet to keep track of content that would need to be reviewed as well as making sure important content is included in the new interface.
The researchers had given me a summary of findings from their research to look over as well as access to raw data. I spent some time reviewing the information to move forward with the design process. The heavy lifting of the analysis phase was accomplished by the talented research team.
There were several new discoveries and more details that came from the research. Below is a sample of the problems found we needed to design a way to fix.
Employees with rejected time off requests has no way to know why without speaking directly to their manager.
Managers couldn’t input reasons for rejection.
Employees could not see a calendar of other employees off that day to know if it was available to take off before requesting.
Managers and employees could not sync their Outlook calendar with the time tracker.
Timesheet forms contained too many fields for most users, especially exempt employees tracking PTO.
Messaging was contained only the system so employees and managers had to log into the system to see information instead of getting emails.
PTO was displayed in too complex of a break down.
From this point forward I will focus more on my role in the project. It was important to highlight the interactions that took place between different team members to understand how I came up with design materials.
This was the meatiest part of the project for my involvement. Design phase was actually broken down into several steps to create our best best guess before testing phase and then iterating upon in delivery. Especially since we were only allowed enough time for a single iteration.
I created a journey map outlining the tasks that each role used and highlighting the most important areas that each role needed to accomplish. For example, non-exempt employees spend 90% of their time filling out timesheets in the system, whereas, exempt employees only log in to request time off and track time off.
That’s not to say there isn’t crossover because all employees would request PTO. It is just understanding the tasks that each role uses primarily to design the system that gives them fastest access to those tasks.
The journey map also included moments that could most intense emotionally such a manager having to handle several requests for the same day and deciding who gets off and who doesn’t. When the system could just stop taking requests when a threshold is met.
There were several new concepts introduced from discovery that design and development need to work on solving. These included:
Robust system messaging
Team calendars with outlook sync
Delegation calendars and split views between delegated team and own team.
Rules engine for automation of rejection/acceptance of PTO and limiting requests.
The process flow was created as a way to map the site out as a whole with all possible pages and roles that would have visibility. It was a way to map out any journey from start to finish and get a sense of navigational elements that would need to be created. This was created using Microsoft Visio. It was a great way for development to get a sense of the amount of pages that may be created and starting thinking of what data structures will need to exist.
Having the knowledge from the journey map and process flow I was able to start in on rough wireframes. Axure was the tool of choice for Wells Fargo. Wireframes were kept to low fidelity for speed and to discourage conversations around opinions of color and fonts as they were established by branding guidelines.
Using my Information Architecture experience I used the process flow to design a navigation system that best fit the tasks that needed to be included. Due to the simplification of the system for each role the navigation was task based on only contained up to five elements.
The wireframes then contained each page needed noting role based visibility, containing important forms as outlined in interactive guide, accessibility instructions, marking areas of content needed for content strategist.
Continuing with Axure I created light interactions to wireframes. I again did not have any focus on visual design to reduce noise and focus on the UX of the product. This was a very quick phase done to give researchers testing material.
The prototypes were given to researchers to look at and do a quick run through for any issues that needed correcting. This included spelling, missing links, navigational issues, etc. We then created a task based test script to test the major functionalities that existed within the system.
For example, we did not test any Outlook functionality as we were not testing Outlook itself and rely on development to implement correctly.
We received a lot of praise for the new designs with only minor issues to fix.
This was the time to implement the fixes to the wireframes. I also updated the wireframes to reflect content from content strategist.
Since the developers were using WFRIA which contained all the branding and form elements there was no requirement to create high fidelity wireframes. We all agreed it was best to not have them either because of future iterations of branding that would change. The detailed low fidelity wireframes were best in marking areas of interaction, form elements, and role based visibility.
The wireframes and prototypes were accepted by the development team and product manager to then implement. This is when my contract ended.
The biggest lesson I took away from this project is that flexibility and agility are more important than pretty visuals. I have worked with teams that want all the deliverables to be exceptionally pretty and polished when they should be looked at as living documents. They will always be changed and iterated upon. Focusing on the process over delivery allows for better use of time.
Though the project may seem like it was short and small it had a large impact. The time off system was used by all employees of Wells Fargo and it was important to deliver a change that was seamless and had a high value add.