I didn’t like PayPal’s UI, so I redesigned it
Background
When given the opportunity to make an individual project as the last part of my UX Design studies at Hyper Island, I knew I wanted to focus on the visual side of things. I’ve been wanting to explore the UI space for quite some time. Building a solid design system, specifically a component structure inspired by atomic design was one of my main goals going into this project. While I feel comfortable with the visual side of UX, being able to make my workflow more efficient through the use of design systems has been something I’ve been wanting to explore.
The Gameplan
I’m an optimistic guy, so I gave myself one week to crack out some solid UI for my portfolio — preparing for the upcoming internship hunt. I wouldn’t necessarily disagree if some might call me an idiot for allowing only ONE week to do this. But hey, agency life is “chop-chop” so if anything, this tight deadline would just prepare me for the industry.
The gameplan was just that, a plan. Plans change and I wanted to make sure I had a very agile approach. Allowing myself to jump between my inspiration board, pen, and paper as well as hi-fi in Figma. Design is not linear and static, but creative free-flow, so this approach was vital for me to get this done on time.
Goals
My goals for this project could be summarized into the following:
- At least 5 consistent hi-fi UI screens that could act as my flagship project when displaying my UI abilities for hiring managers.
- Industry-standard structure in terms of design elements. I would NOT, and I repeat, NOT, make a rectangle and then put text on that rectangle when making a button, for example. I’d put text and then use auto layout with a fill.
- A design system based on atomic design. While I’m obviously comfortable doing text and color styles, the component structure of a design system is more unfamiliar and something I wanted to explore.
And yes, in this order. Things could go wrong, and take more time than initially anticipated so having a clear prioritization was important.
Day 1 — am I an idiot?
By this point, I had identified my victim for this redesign - PayPal. How did I land on this product? Well, I didn’t like how it looked. Simple.
Sending myself into day 1 was almost like jumping in front of oncoming traffic. It was daunting to know that I needed to have a hi-fi interface in ONE week. ONE week. Was I an idiot for even trying to complete this? Before giving myself the opportunity to further degrade me, I found myself doing user testing.
User testing
This is not a UX project, that’s very important to note. It’s a UI-exclusive redesign. But with functionality and the construction of design elements intertwining, I thought I’d be doing myself a disservice to not at least test it and potentially uncover UX issues, that I could address with some new fresh components.
I conducted a total of four people that were unfamiliar with the PayPal app, but are currently using online money transaction apps in their day-to-day. I let them walk through the original interface while they were vocal about the actions they do, why they do it, and what they expect from it. I was observing their actions and took notes. I also gave them certain tasks to fulfill such as;
- “Send money to X person”
- “View how much Euro you have in your account” (while the default currency being GBP)
- “Change the details of the card ending in ****”
At the end of the test, I asked questions regarding certain actions they made and the general interface design.
Some quick insights from this testing were;
- Scannability and nudging in the UI are lacking. For example, “Edit” and “Remove card” have the same style.
- The flow of the app is familiar, predictable, and quite seamless. This further encouraged me to make this a UI-exclusive project.
- The main card is not recognized as clickable.
UI analysis
While the title “I didn’t like PayPal’s UI, so I redesigned it” is accurate, it’s not telling. A descriptive word I’d like to use is “inconsistent”.
I also took Nielsen Norman’s 10 usability heuristics into account when analyzing parts of the interface. The first one, visibility of system status, stood out to me the most. An example of a successful follower of this heuristic is the “You’re here” pin on a map. The tab bar of PayPal is their “map”, kind of, but the problem is that the “pin” (selected page) is very hard to distinguish from the other two options due to the contrast. A small thing in the big scheme of things, but this is how I used an industry-standard directory, Nielsen Norman’s heuristics, to study the interface.
Day two — getting inspired
Getting into the design phase, inspiration is number one. So, I made a moodboard in Dribbble. This platform gets a lot of sh*t for just being flashy interfaces without taking UX into account, which made it just the right place to go for this project! Jokes aside, this allowed me to get a finger on the pulse of how one could use layout, color, and typography in an experimental way. Say what you want about dribbble designers, but damn they really are experimental.
Day three — Figma time
Today’s goal was to set the design. This would normally be a stage of pen and paper, boring grey boxes, and lorem ipsum when building an interface from the ground up. Luckily for me, I had a whole existing app as a reference — an app whose flow and content had proven to work. I deemed it inappropriate to go through that lo-fi stage for the whole app just for show. It didn’t make sense for the stage I was in.
I fleshed out the home screen to a mid/hi-fi to use as a reference to the rest of the frames. This screen defined the typography, use of colors, buttons, and spacing. I wish it was this easy as I make it out to be. Important to note is that I still had a very agile approach, where I switched between my inspiration board, Figma, and sketchbook.
I just took a stab at lo-fi and said it didn’t fit my project, but it did for certain individual components where I quickly explored different layouts, such as the main card.
Day 4 to 6 — establishing consistency
I now had the text and color styles defined along with buttons, icons, and spacing which made these upcoming days a blessing. Having my styles pre-defined in a design system helped a lot with ensuring consistency across frames while also speeding up the process of designing. Not only is it easy to just tap a style and apply it to an element, but if you know where each style should go, designing an interface becomes a no-think process which is just amazing.
The atomic design system challenge
One challenge I encountered was the component-structure. As mentioned, I wanted to replicate an atomic-like design system but this turned out to be a struggle and only halter my process. The atoms were easy and defined, but moving those into molecules and organisms with proper auto layout that would be industry-like was a struggle for this short amount of time. I underestimated the effort of developing a fully connected design system, and with time running away, I decided to stick with my atoms and combine those when needed.
This created a very specific problem I wanted to solve by applying atomic design in the first place. I realized when mirroring the interface onto my phone that the circle should be 44x44, instead of 36x36, due to legibility. I could quickly change to the desired size as all the circles were instances of the same main component, but this messed up the alignment with the rest of the close-by components as they were not connected with one another. While fixing the alignment only took me about 2 minutes on them all, it would’ve taken a total of 2 seconds with a fully connected molecule. Those are the small details I want to improve in my UI workflow.
Day 7 — pulling it all together
Coming into the last day, I was comfortable with the design and the way it would play a part in my portfolio and had some solid feedback from my fellow Hyper colleagues. It’s consistent and defined, which you can’t say for the current interface.
What are the next steps?
The next step would be to user-test this iterated interface. It would be very interesting to see how my redesign compares to the original. While the flow is mainly left untouched, the visual weight is different and how that would change the outcome of certain metrics would be, not only fascinating but crucial to know before trying to launch.
But after that, structure a Figma file that would be ready for development. Prototyping, defining animations, and adding comments before sharing it with developers to ensure the product created in Figma translates well into a coded format. If this would be meant for development from the get-go, I’d make sure to involve a developer as early as possible for them to point out potential limitations and opportunities.
This is NOT shippable
I would never consider this a shippable product though. But, that wasn’t the point either. The goal of this project was for me to explore the area of UI design a bit more. It wasn’t about UX, but crafting a cohesive visual design. This, surprisingly, made it difficult. With UI and UX intertwining with each other, it’s hard to totally ignore one to focus on the other. They co-exist and should be treated as such.
A well-visually designed interface doesn’t mean good UX, and then it won’t have the desired impact in the real world. The process of emphasizing with users is too valuable to ignore when creating real value.
William Grånefors — Hyper Island UX23