Users needed a way to set and manage their company's budget for individual services provided through the LOCALACT platform for up to 15 months in advance. It needed to be included in an existing page with additional functionality as a single form. The Angular developers had already done some work and determined this form should be in a stepped wizard type layout.
This was my first project and the main reason I was brought in on a contract at Location3. Given the problem with few other requirements, I wanted to start with by identifying the simplest solution. This was a quick form with a select dropdown menu to choose a specific month or all months along with a numerical input for the budget dollar value. I started by adding this solution to the existing page layout without worrying about wizard requirement. After presenting the simple solution to stakeholders, several additional requirements were uncovered and added to the scope.
Along with the original requirements, users also needed to be able to see and compare all 15 months at once, like a calendar. They needed the ability to input and edit all individual months. Users also needed the ability to “Pause” any month where business may be slow or non-existent for holiday dependent industries. Data to display in each month included the month, year, a line for the previous year's budget, total budget for that month (which included a calculation of the amount entered, fees, and corporate budget). Developers were also requiring that this be in a single form with other components.
After the first round of design reviews, it was clear that I needed to take all of the new requirements and go back to the whiteboard. The solution quickly became a complex form with a significant amount of data for the user to digest as they are making budget decisions for up to a 15 month period. I needed an idea of what this might look like.
Initially, I thought we needed a way to toggle between the simple form and the massive 15 month form. I was assuming that most users would prefer one view to the other. What I didn't realize at the time was that we would eventually be including more pertinent data for each of the month cards. Basically, this would require every user to look at each card to make a decision, rendering my simple form idea useless.
Once I understood the requirements better, I designed what a monthly card would look like. It included all of the required data and functionality. I used font-weights to draw the user's eye to the dollar values. I hid the “Total Budget” calculation break down behind a hover tooltip and used a simple checkbox for the pause functionality.
Then I began designing out the entire page. The wizard requirement became a sticking point for me. It didn't make sense to send the user through a step-by-step wizard every time they wanted to view the Monthly Budget Management. So I convinced the developers to drop that idea and treat this page as one with a few different components that would be independent of each other. Because this page felt so long, I wanted to include a filter for the user to view any specific month they want. The result was a very long page, but one that met all of the current requirements.
After reviewing the V1 designs, we decided that the simple form idea would need to come back into the fold. Some users would only need a single budget for all 15 months. I added a numerical input to the top of the form that would apply to all months. I used an icon button as the submit action for the input with a tooltip to reduce text on the page. This ultimately would be changed to a text button, as some stakeholders didn't understand the functionality. I also included a small caret button in the top right of the panel to roll it up at any time to see the Payment Method section (this would eventually be moved above it, but the team didn't want it moved at the time).
This was technically the end of Phase 1, though it was not fully planned out this way. Designs were approved, but the lead UI developer had just been let go. I offered to help out with the front-end development, and then work with the backend developer to get this page working. I built the fully-responsive UI foundation in Visual Studio Code with HTML5 and CSS3 in an Angular environment. Before the page was ready for deployment, we received new requirements...
Each month already had a "status" applied to it behind the scenes, but we needed the user to be able to see it. I was given the list of statuses and the task of designing them into each monthly card. Additionally, stakeholders insisted on adding more budgets to each monthly card. Stakeholders also didn't understand the icon submit button for all budgets. There was a miscommunication with the developers at some point about how this form would be saved. We agreed that there needed to be one main button for confirming the page updates.
In my mind, these new requirements would turn an already long page into a long and messy page. I wanted to add the new content in a way where it wouldn't overwhelm the user. I started with the statuses. Using the given list, I created an icon system using Material Design icons that we could put into the empty white space of each card. Using icons and colors would draw the eye to it but not distract from the other content. I used hover tooltips for explanations of each status, with the hope that users would eventually learn to identify them with it.
Next, I focused on the additional budget data that needed to be added to the UI along with updating the submit button. I confirmed with stakeholders that the “Corporate Budget” and “Total Charges” lines were the most important lines for the user to see. With that in mind, I designed a toggle switch system to hide/show the “Monthly Budget” and “Total Budget” lines in the UI. It would simply expand or collapse the monthly cards. This was an accepted solution by all stakeholders. I also developed this feature into the page using Material's toggle button functionality.
That was the end of Phase 2. The page was built and deployed to production. It was a long project and the team was glad to get it off our plate.
After being live for several months, quite a few bugs had accumulated and we needed to make some development changes that would affect the UI. First, was that many users were not finding the “CONFIRM MONTHLY BUDGET” button at the bottom of the page. We suspected this might happen but stakeholders wanted to ensure that users would scroll the entire page. To fix the bugs that the developers were working through we needed to add a confirmation page to ensure all of the data and payment info was aligned. Now that Recommended Budgets had also been implemented into the platform, we needed a way to apply them from this page also. Stakeholders wanted it to be the most prominent button.
I recommended that we move the Payment Method section above the Monthly Budget section to ensure users would not miss it, as well as fix the confirm button to the bottom of the page so it would always be visible. If users needed to enter data or fix something, the button would be disabled. I also recommended that we update forms for updating payment methods as they looked outdated.
This was my first project with L3, working on a contract—it eventually led to being hired full-time. In hindsight, I would have liked to have met with all stakeholders earlier on in the design process in order to gather more requirements from the beginning. This would have resulted in a more efficient design process and yielded earlier success. Overall, it was a good introduction into the company.
Design processes are important. When a company doesn't have one, it is a perfect opportunity to create one that works best for the team and business goals. Additionally, Figma’s advanced features and components can make these processes even more efficient.