Online Finance Management Portal (OFP), manages incentives and other finances between a very large tech company and their ‘Partners’ directly setup within this program. This tool manages finance profiles, incentive portfolios, claims, earnings, taxes, and payments. This project is a complete overhaul of the current site and all of these features.
Due to NDA, confidential information and content has either been omitted, modified or substituted to comply with coorporate policies.
Almost all meetings involved whiteboarding or sketching thought-process and interaction.
whiteboard concepts were photographed and built into rough wires for team/peer reviews.
Wireframes that showed merit were built using a new UI framework and HiFi flows were made for further review.
I worked very closely on key features that were own by individuals, and teams locally and globally.
An agile environment required structure and planning, reoccuring meetings, review sessions and organization.
Engineers initially collected engineering metrics from Azure, but eventually used observation sessions and flighting in means of collecting usability data.
From key features to individual elements, everything was presented for peer review, feedback, iteration, refinement, and final signoff.
All deliverables followed the same style treatment, direction or instruction. The Engineers were provided end to end flows for each full interaction.
Inheriting a two sided platform. After 4 months of being a team of two and updating content by request, my lead left for better opportunities and I inherited the project as a whole and all of their remaining responsibilities that came with it. Basically, I ended up taking complete creative ownership of a multimillion dollar finance management tool for one of the largest tech companies in the world.
"I ended up taking complete creative ownership of a multimillion dollar finance management tool, for one of the largest tech companies in the world."
My responsibilities placed me square in charge of creative direction, project management and all executable work for engineering teams, and account managers that made design requests. To make this redesign successful, I worked closely with stakeholders, engineers, project managers, account managers, and engineering leads within my org. I took complete ownership in collecting content, and working through each interaction, business requirement, and user need working from initial whiteboard concepts through to completed flows. All creative work came through me.
Bringing O.F.P. under a larger company framework. The tool was originally built not using a unified framework or following any of the bigger UI guidelines within the company. Elements, interactions and features would vary page to page; the experience was broken from the get go. After about 7 months and 5 different frameworks, I was finally able to bring O.F.P. under a unified framework.
Mastering the bigger picture. Sometimes the bigger picture is very big. I was required to know each interaction, each user goal and each business requirement for each feature of the site. Seeing the bigger picture was the hardest challenge of all; from all of the features in and outside of OFP, learning how each of them functioned and initegrating them into the site. As the sole designer on the team, I had to know everything.
“Seeing all of the features in and outside of P.I. as a full picture, learning how each of them functioned and needed to be integrated into the site was the biggest challenge of all.”
No active research to drive design. I was forced me to ask a lot of questions and pushed the engineering teams to think more like a user. It pained me to see the time and money invested on a design, coded and pushed live with no further review or evaluation to see if a design was the right solutions. Educating the importance of planning and using collected metrics to drive design changes was incredibly challenging. Better qualitative and quantitative data was a new primary goal during my contract.
User goals.OFP’s gateway was seriously lacking in information and effective navigation. It also has a tendency of dropping key features out of the fold, making them completely unknown to users. My vision was to bring better insights to the users data and improve navigation to key features.
Business goals.Redesigning the site in the beginning wasn’t prioritized, meaning no budget. But they knew they wanted to reduce support tickest from users, eliminate financial errors entirely and build better management systems for their tax and banking profiles as the company expands to new markets.
Rebuilding I.A.First step, was to remove pages that were either non-functioning, outdated, or not relevant to a full functioning site. Secondly, many elements throughout the site owned entire pages, so consolidating features and make them work together more fluidly would further simplify the site architechture. Lastly, I worked with the engineering teams to build a single page application using Angular JS. this helped drastically reduce site interaction.
Simplifying the I.A.The current site had a lot of outdated and confusing interactions, so consolidating features, and redundant page; removing dead ends and nonfunctional content down to a simplified version and building up from there was priority. The engineering team was also using single page applications with angular JS, further helping simplify the IA.
A new framework. Most of the presented data differed subtly from page to page, save the forms that were almost entirely different from experience to experience. It was decided that MWF was a new framework that would unify the UI for all of OFP. Giving all forms, fields and data sets the same feel and flow; providing the same interactions from user flow to user flow site wide. It also helped guide any new content intruduced into the site. Starting with the biggest hurdles first: the Homepage, Co-op, Claims and Payments. Everything else fell into place after.
Two sides of the same coin. Externally, there are only two user types. Internally, there were 6 with more user roles being added. Some of these user roles have limited views, or only see one or two key features on certain pages. Other roles see everything or everything pertaining to specific function, like payments or claims. I needed to make sure the new look would work across the site for all user.
Write, view and inaccessable privileges were predetermined and organized into lists for easy reference. This helped guide content through consolidation efforts.
Project management. Each increment was planned carefully, structuring work between engineering requests, projects outside of the program and building future state content. Prior to my being on the team, the design requests would come directly from the engineers in the sprints they they were working on. This was problematic, causing workload to fluxuate drastically. So to start, I worked with each team at the beginning of each increment to plan out the next 3 months of sprints. Smaller simplier updates or modifications would be done near the end of the increments while longer more involved interactions would be moved to the beginning; allowing room for multiple iterations and feedback.
Divide and conquer. OFP is comprised of 4 major sections: the Homepage, Co-op/claims, Earnings and Payments. Everything else is either support systems or minor interactions. Outside of a normal site structure, Every feature of the site can be broken into two major systems: data visualization and form entry fields. Basically, a user is either viewing data, or entering new criteria to modify or update that data. Each interaction falls soundly within those two systems.
Sketches and ideation. All features began with meeting stakeholder and discussing direction and business requirements. We should sketch through the interactions and address challenges or updates. Depending on requirements, additional meetings would be required to completely walk through all needs. And finally, based on initial ideation and sketches, a direction would be decided and explorations would begin.
Journey and flows. Flows were used to control process and guide meetings from week to week. Many features would flow together in a single journey. These allowed us to invision the bigger picture clearly and maintain a thorough insight as a whole. A number of our interactions involved many steps; user journeys allowed us to addressed these accurately and quickly.
Wireframes and mockups. Most work was done using Adobe Illustrator. This allowed me to build everything from basic flows to layered hi-fidelity mockups. The UI team at BTC had provided templates of elements, controls, and key features to build from removing the need to rebuild each new element. With almost all of the content already built, this quickly sped up productivity leaving plenty of room for exploring interactions.
Features like the Gateway, Co-op plans and some of the more broken or business heavy features required more attention and exploration. Below is a small sample of a few components and interactions explored.
Dashboard. The dashboard below is an original state for external usin; internal is almost identical with additional tile sets. It doesn’t provide valuable information in useful ways. The primary use of the tool is to manage finances, but nothing on this gateway suggests this. In addition, the gateway is the only place on the site to use a tile system.
In a nutshell, the goal is to provide all user with a high level view, see updates, alerts and actions quickly all without having to dive deeper and hunt for that information. Ultimately, insights from a thirty foot perspective.
Data visualization. The payments feature was entirely an internal process executed outside of the program and developed by an admin in Excel. Initially managed easily in a spreadsheet, but as the program grew and more businesses were onboarded, it became problematic to manage thousands of payments. The data became too large to process without error, and inturn too risky to release a Multimilllion dollar payment without proper checks and balances, Using the success of table interactivity from Co-op plans and MWF, we migrated payments into the tool utilize the backend database.
Interactive table sets. Some features required further interactivity within the data tables. Featured below are explorations I created for tax and bank profile input and management. Because of the multiple types of profiles, input methods and management sets, we decided to build the interactivity into the table itself. Below is only a brief sample of one exploration for interactivity within a table.
Forms. The claims process required submission of physical proof of executions for specific activities. Proofs often were rejected for various reason, We needed to privde better reminders, direction, and instruction for correct proof uploads throughout the period. Below is a section of the form with call outs to issues discovered.
Issues in the form above are informational, contextual, instruction, or basic layout. MWF help clarify direction to the user. The current top down flow was also challenging to use. Additionally these features need to be accessable by partners and internal validator roles continually. Featured below is a sample for both external and internal of new input features, instruction, important values, feedback systems using the new framework.
User observation and flighting. While PI didn’t do much in the way of research or data collection outside of engineering needs, I made it a personal goal to emphasize its importance and to continually emphasize the need to collect usability metrics. From this, the team started adding usability quiries into the Azure data lake to start collecting metrics on new features as they were added throughout the tool.
As we finished the dashboard, we flighted it to a small percentage of users throughout the site randomly to test viability. When acceptable, we pushed to the whole market with the ability to switch between the new gateway and the old.
Co-op plans slowly rolled out over a few months slowly changing as we went. We flighted to a previously selected user pool, already approved to test new products and interactions. These users were prepared for the update and provided helpful insights to their needs before we started the redesign. They were first to test the new features and provide direct feedback.
We ran weekly observation studies for each process of updates made to the Enrollment section. Not necessarily as guided as desired, but I was able set specific targets to observe and validate specific functionality as the studies progressed.
Deliverables. Each feature would be pushed one at a time. I had distributed the main elements of the site into major groups allowing the teams to tackle them with more control. Starting with the Dashboard as the turnkey for the whole site to follow. Afterwhich each major section of the site was updated and pushed to engineering for development. The features below are only a small look into the site as a whole and all of this intricasies.
Media intended UI for a data driven site. The UI was built for sites that were originally developed for retail sales, music, product promotions and other visually stimulating content, like the primary store page of BTC. Using a graphically heavy UI for a data driven site felt like building a log cabin, but only being able to use kindling. Being heavy on data visualization, without the imagery to break up plain text, it guided me to build the site, lite and airy. I enjoyed the constraints and ultimately feel the outcome was an incredible improvement compared to the original state.
Fish out of water. My entire org. was an engineering team. Having a designer on an engineering team was an anomaly, but progressive and needed. Good design is an iterative process ,rarely linear, and takes time to work out successfully; not an afterthought to an engineering need. Engineers would make design requests like code changes making any real progress on a project almost impossible. It took months to guide and change the way engineers came to me for needs. It only took an increment to learn, adjust and ammend my position on the team. Ultimately, design needs were no longer last minute requests, but planned months out allowing for exploration, iteraction and review.
Project management. Being the only creative meant a number of things: I had to manage my own workload from team to team, sprint to sprint until I received a dedicated project manager near the end of my contract. I had to be self-management, scheduling, planning, and organized. I structured everything from meetings, peer reviews, updates to my own workloads up to three months out. All of the future state content was also unprioritized; I had to take all of the workload unto myself to get it done. This was a future state they couldn’t budget for, but wanted and needed badly. So in the downtime between prioritized projects, I made changes and updates slowly progressing over a year. I learned how to be a better project manager, planning far ahead and working backwards planning all the way.
One of the best contracts I have had. My final thought is this; I didn’t know I would enjoy working at BTC as much as i did, but it was one of the best opportunities in my career, I am extremely thankful to my team and to the people that helped me complete this contract so successfully.