top of page
Billing History
WriteWay Account / 2021
The Payment and Subscription pages were a large feature that needed to be completed to prepare for the launch of WriteWay Writer. Within this, I worked on the Billing History page: A place where users can view invoices for their past payments. I worked closely with Lucas, a Product Designer on my team who was working on the Payment and Subscription pages, to ensure a consistent flow from signing up to viewing invoices.
My role: I was the sole Designer of the Billing History page. However, I closely collaborated with Lucas, a Product Designer on my team who was designing the Subscriptions and Payment pages. I also collaborated with my Supervisor, the Product Owner, two Back End Developers, one Front End Developer and one Software Quality Analyst.
UNDERSTAND
Technical Requirements
To kickoff the beginning of this project, I met with two Back End Developers and the Product Owner to understand the detailed technical requirements of Billing. From these meetings, I gained the required elements of the Billing History:
-
Date Paid
-
Type of Subscription
-
Payment method
-
Status (In this case, it was only “Paid”)
-
Total Amount Paid
-
Button to open a PDF Invoice
I also learned the required elements of the PDF Invoice that would be linked to each Billing Line. I met with Lucas (Product Designer) and my supervisor to brainstorm the information architecture for Payment and Billing History.
Competetive Research
With the technical requirement underhand, I wanted to gain a better understanding of the conventional billing formats and research the Billing from other sites.
From my research, I found that most companies included a filter, search function and/or a Date sorting feature. I discussed this with the Product Owner to see what was in the scope of Version 1. We collectively decided a sort-by-date feature would be a good addition so that users can easily find their oldest/newest bills. In the future, a search feature and filter will be added so that the user can have more control over what bills they see and have a better search experience.
EXPLORE
Wireframes
Since Lucas began Payments before I started Billing, I was able to use his Payment page as a style guide, so that we had consistent headings and typeface. I started my wireframe process with simple sketches to get a feel for the structure. I then moved on to some higher fidelity wireframes to test out the UI. Since this page has a lot of content and information to be read by the user, it was important that I play around with the spacing of elements to ensure accessibility.
My initial design was a foot in the right direction, but it had its design problems. The text fell flat, and wasn’t exemplifying any level of hierarchy. It’s important that the user can quickly glance at their previous bills and gain the information they need quickly.
As well, the “Paid” status labels looked like buttons, which wasn’t the intention. I knew I had to work on making this label look more like a message than a clickable item.
Lastly, the kebob menu at the end of the billing line was causing the “View Invoice” Call-To-Action to be less discoverable because it's hidden within the menu. It also added an unnecessary extra click to access it, when there was only one menu item within it.
I also had some concerns from stakeholders, such as why a status was being included if there was only one type of status (which would be ‘Paid’). I backed up my design decision with user-centered explanations on my wireframes and we were able to come to a decision to keep the status.
REFINE
Design Solutions
After more rounds of iteration and feedback, more hierarchy was added to each billing line. The ‘paid’ status was changed to a green solid label to look less clickable and illustrate a happy confirmation. Lastly, the dropdown button was changed to an ‘eye’ icon to describe a viewing action and lead the user to the Invoice in one click instead of two.
I met with Lucas throughout the process to ensure our designs were consistent and he adopted some elements of my design such as the “Back to ….” button. Meeting with him constantly ensured we were always on the same page but also was a great way to get frequent feedback.
REFLECTION
Early Breakpoints
This was one of the most technically challenging projects I’ve worked on. It was also the closest I’ve collaborated with another Product Designer at LST and the most I’ve worked with Back-End Engineering. (A lot of firsts!)
This project helped me build relationships with the BE team and figure out a flow of communication that worked best for understanding requirements and asking questions. It sparked the creation of specific scrum channels that helped guide the discussion and made it clear who I needed to talk to.
If I were to do this project again, I would have liked to consider the breakpoints earlier on in this project. Many sources say to focus on a mobile-first way of design so that you aren’t “cutting down” the experience as you get to mobile. After working on the Billing History, I began the Account Responsive Design System so that I could ensure all screen sizes were being accounted for.
bottom of page