This is an umbrella feature being added to the Online Finance Portal (OFP) for Big Tech Company (BTC). As an integral part to OFP's success, it encompasses many features, users, and interactions. This showcase illustrates process from inception to delivery.
Due to NDA, confidential information and content has either been omitted, modified or substituted to comply with coorporate policies.
Meetings often began and ended working out concepts on whiteboard.
Whiteboard concepts were photographed and built into quick wires for stakeholder reviews.
Wireframes showing merit were built using a unified UI as end to end HiFi flows.
Weekly meetings with the project owner, stakeholder, or team for design and code review.
While the project owner prioritized and managed this project, I was responsible for managing the creative work and delivery.
New features were rolled out in stages, flighted to a select user pool collecting data for informed future improvements.
Key features to individual elements; everything was presented for peer review, feedback, iteration, and refinement, for final signoff.
Following a unified style treatment; redline instruction as full flows were provided for the dev teams for complete end to end interaction.
Mastering all components and interactions. Being the sole designer for this feature required the full understanding of all its components, its users and their interactions with each other from end to end. Everything had to be completely understood down to the last pixel.
Digitalizing an analog experience. Most of this feature is an update from a pen and paper form. This involved building a new feature into an existing platform that already contained part of this process.
Pushing Business. Because there are so many depending actions new and existing, this feature needed to be seen as more than just an add-on to the portal. I needed to argue its importances as a key features to the site. Convincing business of this importance was more than challenging.
Accommodating a new UI late into the project. When the project started there was no clear defined UI to follow. Halfway through, the team landed on a framework that was still in development. Near the completion of Updating Co-op plans, the new UI was finalized and existing designs needed to be updated. This challenge pushed us back to the drawing board more than once, but help simplify a few experiences along the way.
Desigining for multiple user roles. Primarily built for the external users or BTC clients, this also needed to accommodate existing and new internal users along with accessability limitations.
Defining user goals. This was defined by collecting insights by interviewing internal BTC employees, and sharing perspectives, and the requests made by them and their users. User goals and business requirements were built from these insights.
Business requirements. These either came down from Business or Law and were further defined by the project owner and modified by stakeholders. Each requirement was built as a feature and executed over 6 months of sprints.
User journeys and workflow. Close collaboration with project owners and stakeholders helped to define all user roles, portal automation and individual interactions in a end to end journey. This is why mastering the project as a whole was so challenging.
Making a case. This project started as a brief presenting the needs for improving the analog experience to business. The owner came to me requesting basic wireframes to illustrate improved interaction for budget approval.
Feature and sprints. Features were addressed and assigned throughout the increment from sprint to sprint. Each feature was a different business requirement. This was our process discuss/review, update, redesign, repeat - deliever to developement teams. The explorations below show how a table changes over time as the requirements and content evolve.
Failed explorations. User requests and goals weren’t always necessarily made into features or business required. Before taking on the new UI. Many explorations were considered; this is one of many failed explorations before I landed on a solution using MWF.
Explorations for data visualization. Most of the tables were long and flowed out of the fold. I divided the content into primary and secondary content; displaying the most pertinent information in the table and drawering the rest. The drawered content would have cues that would call to the users attention.
Deliverables for the dev. teams. The Feature below is one way we addressed validation outside of Co-op plans in the tool, This step to step flow with redline is an example for dev build instruction.
Flighting. There were small steps to validation but some is better than none. When a satisfactory build was completed by the dev team we rolled the new update out to a small user pool. These users were informed of the changes and were prepared to collect and provide feedback on specific interactions. This feedback would be updated in the next iteration and pushed on the next update. Week by week minor changes were made to the tool, to accommodate user requests.
Typically features would be rolled out in stages, but for this project as a whole it was an entirely new experience, we needed an end to end understand how our users would take to the new feature. I had also worked closely to the engineering teams to integrate more user metrics in the data collection on the back end as well. This was to help provide better insights to future updates and builds.
Plan management. All plans for a partner can be broken down into 3 major sections, the first is plan management landing page or the gateway to all plans. This is a complete listing of all geographies for that program and the plans associated to them, current and past. The views below are the final update for both external (left) and internal (right) users.
Co-op plans. The second section is the plan itself. This is a listing of activities added to the plan in a list and displayed on a timeline. Other pertinent information for the user is available to view at a high level without having to dive into the activity details. Total funds are listed for the plan, as well as allocated funds per each activity. And lastly any specific action a user may need to execute per activity as well as action triggers. The views below are for both external (left) and internal (right).
Activity setup. The last section is the supporting content to make the plan work. Each activity needs to be added to the plan and be configured. Each activity must be configured, reviewed and approved before they are able to make a claim. This is exactly as it was before an online version, but managed all digitally under one system.
7 sides to a coin. Building for internal and external users was one aspect, but having multiple internal user types with limiations to accessability was challenging. Again, another aspect of knowing the project as a whole was key, as well as being able to build with the new UI. Having this guideline to hide/omit/display was key. Alway keep an open mind and think a little bigger.
Managing complexity. Features were built throughout sprints based on complexity. Various teams we worked with were spread all over the globe from India to Ireland. Designs were completed either in major end to end flows, or breakouts of individual features. All of this had to be organized and structured accurately to not waste time and money. If anything, this project has taught me how to organize and structure.
A designer team of one. Being the only designer on a team has its benefits, but ultimately having a team to reflect, share concepts. recieve feedback (good or bad) is always better. If I had to do it all again, i would have fought more to be apart of a full design team. I feel this would have sped things up quite a lot and allowed for an even better solution. iEither way, I am happy to be able to deliver improvement alone, and to be depended upon by so many intellegent peers.