Project summary

The first of three major projects I developed at this bank.

A solution for staff briefings at branches. The project aimed to improve the current solution with better functionality, a more up-to-date UI, and a thoughtful display of information when needed.

Team

• Department director

• Several other people from the business

• 2x UI / UX Designer

• Many users

The requirement for the application came from the managers and directors themselves. This was my first project there, and as it sometimes happens, the deadline was already close.

First insights

• The current solution was super outdated. It was more like Excel with extra steps, but worse.

• Whatever we create, we have to test it with users, because they will be happy about anything.

• That kind of functonal jumps works best with iterations

• Too much information at once

• A lot of horizontal scrolling

• A lot of data that even directors didn’t understand.

• Regular employees didn’t understand the interface, and it was challenging for them to use it.

Interaction example

An example of how bad it looked and the interaction that the solution had.

The first deadline was impossible for quality.

The problem was easy to verify. The interface at every step was simply bad and slow, but it worked. The first deadline I received was 2 weeks. Received, because the deadline was set before I joined the project, as it often is.

The first idea? In 2 weeks? Slightly better charts and a better table. Visually better and improved table functionality.

In two weeks, miracles won't be achieved.

Better organized information in a better-looking table.

And here I collided with a new approach. The table would not meet the requirements, but it would meet the deadline. What do we do? Here, it was more important to deliver a good solution, not to stick to the budget strictly. For me, this was no small surprise, but I was also pleased that we would work to deliver good UX. Since there was pressure on the project and I had just started working,g I got a designer to help.

We also received approval for creating it as we want to. We decided to use as much of our web design system as possible for clients, since there was no design system for internal solutions.

Field studies and user testing

We mapped out all the data and understood how it was grouped. We wanted to make sure we understood everything and that we won’t miss anything. From that point, we could narrow down to what is really important.

To see how users use the current solution, we went to the bank branch for a briefing a few times. First, do see and understand, and then a few times for clarification and additional questions as we design the new interface. We both observed the whole process and took notes. Whenever one of us asked additional questions or guided users around the interface, the other took notes.

For obvious reasons, I didn’t took any pictures from that activities.

Cooperation

It was the first time I worked closely with a second designer. I loved our iterations and quick ideas on the same project in Figma, but I also learned how people approach design differently. I was a bit slower, but I always used auto-layout. My college was a bit faster, but used less autolayout.

In the end, I now think it’s always good to have at least one support designer, just to get quick iterations and idea verification. Or to get through anything that slows you down faster.

While it’s difficult to pinpoint who did what exactly, since we gave feedback to each other all the time, I can highlight that the charts on top and right came from me, while the table came from my colleague.

Interface and challanges

We based our UI on an existing web solution. We used the same colors, fonts, dropdowns, and many more components, as it makes sense for every possible aspect.

The biggest surprise in this project was the switch in technical approach halfway through. However, the solution will not be created from scratch; it will be built within the existing ecosystem. I remember the surprise when another team showed up that said they would rise to the challenge based on the brief.



After 2 weeks, I only realized that they had no contact with the previous development team and no one had even sent them mock-ups. I guessed only after they said they needed mockups (which had been provided to the earlier team 1.5 months earlier).

A quick explanation with a little demo of a similar solution. I’ve changed a few things because of the NDA, but the idea stays the same.

Summary

I loved the idea of quality over the rest, and in just 2-3 months, we were able to provide a really good solution. I know it was decent because of whole team of really experienced designers agreed that it was. Additionally, we know from testing with users, but we should've done more testing.
I highlight feedback from other designers, since users would be happy with almost anything, given that the old solution was so outdated. As a designer, you have to take that into consideration.

• Users were happy, cooperation was great, so I was happy too.

• Help from other experienced designer who wokred longer in this bank was very important.

• Many directors around headquarters knew about the new interface, but as it turned out later, that was it. There was no communication or tutorial on how the new interface came in.

• I personally learned to be bolder with ideas and propose an easy and preferred solution.

What should be different

• Consulting deadlines with designers to make them more realistic upfront.

• Aligning on goal and values at the begninig of the project

• We should’ve communicated and tested with more branches than we did

• There should be short video presenting changes in interface. As I did above as an example. I didn’t know there wouldn’t be anything like that, but after I found out, I suggested making a short video.

• There were some development challenges here because there were no developers involved in the project upfront.