Because I am unable to showcase the work I did for this project, I wanted to shed some light on the processes of how our team redesigned a mobile application, created hundreds of components, and had them ready for the development team in just two short months.
When I was brought onto the project I was told I would be creating and re-designing assets for a mobile application used by hundreds of thousands of users daily. Some pages would need a complete overhaul while others would simply be a one-to-one re-skin. While this sounded straight-forward, the current app had been cobbled together by multiple designers and developers and had no uniform consistency in its components. For example: a CTA button used on one screen would look entirely different on another. There were dead ends in the flow and redundancies that needed to be addressed app-wide. It was a lot of work, but thanks to the all-star designers and Project Leads, they audited the entire application and broke down each page and its components as if taking apart a jet engine and sorting out every single bolt and screw.
The workflow was broken up by “flagship” pages that were both the most-visited pages in the application and the ones that contained a diversity of components. The scope of our re-designs were defined by three “Levels of Effort” or LOEs. These determined how much freedom we were given to overhaul a page. An LOE1 page meant that it was a low Level of Effort and that was to be a one-to-one re-skin with our newly-designed components, while an LOE3 page needed a total redesign. The LOE3 pages were definitely the most fun to work on as they included custom components; the higher the LOE, the more freedom we had as designers.
The Project Lead created a Leankit board (essentially an online SCRUM board) and organized the flagship pages into “parent cards.” With the work divided up, we each assigned ourselves to parent cards and were responsible for the components that were contained in each of those. These were called “child cards”- nested cards inside the parent cards consisting of link elements, CTAs, selectors, etc.
The application needed to function on both IOS and Android, so we methodically combed through both Google’s Material and Apple’s HIG Design libraries to find complimentary components that would ease the strain on the developers and help us establish interaction rules. As we worked on plugging away these components in our explorations, our formal design system began to coalesce: we made rules on hierarchy, typography, and a universal grid. All the while designing custom components that had no Native equivalent.
Every week we would have mid-sprint check-ins with the client where we would showcase our progress to make sure we were aligned on design and direction. By the end of our final sprint we had created hundreds of components. We symbolized them and compiled them into two massive libraries so it was simply a matter of plugging in our components to have the final pages ready for delivery. With our library in hand, the developers would be able to implement and sort all of our designs with ease, (something they greatly appreciated.)
The final review was met with nodding heads and overall excitement/relief from the client. My favorite moment was when the director on the client’s end, in a pause near the conclusion of our presentation, looked over our design team and said “This looks SO much better.”
This was one of the busiest projects I have ever worked on considering the turnaround. Thankfully, I was surrounded by driven, creative, and excited designers. Being around that type of energy is one of the best perks of being a designer. I would work again with that team any day.
Back to Top