An internal product, a financial app that gives an overview of the incomes from our products and gives detailed cash flow statements
© 2021
The interface of the existing web platform is unfriendly to the user. There was no way to quickly access key financial metrics of products within the company. Transaction data is fragmented and cannot be obtained without generating an accurate query to the database.

As a result, it is necessary to request this data from project managers, distracting them, as well as designers who have to design the data into a presentable form. This time can be spent on tasks that will bring more value to the company.
A team of 5 people was allocated to develop this project:

2 developers, 1 analyst, 1 project manager and one product designer (me). It was an end-to-end design process, 1.5 months long. During this time, I did the user experience design including user research, new user flows and the new information architecture.

Developed low and high fidelity prototypes and created the final visual design.
My process will be different from a project to another and will be influenced by many factors such as the project deadline, current stage, complexity, etc, nevertheless, I try to go through every stage of my interpretation of classic product development and try to validate my decisions as soon as possible.

When designing a product today, it's both impossible and unsensible to set up a rigid process and follow it for every situation; we need to be agile and quick to adapt. It is necessary to have an outline of the design process you will follow. If the results are not satisfactory, you can go back and analyze what you did wrong and improve the process. If you did things randomly, you would always get random results.
To understand the problem, the first thing I did I collected all the information available at the moment. Fortunately, the project manager acted also as the end-user and one of the project's stakeholders. She had managed to collect a lot of primary information about the limitations of the current platform, wishes and my task was to study and organize all the data.

I was interested in the answers to the following questions:
★ What problem do we try to solve? What is our goal?
★ What are the constraints and challenges?
★ Do we know our users? Who is doing What? Why and How they are doing it?
★ What will be considered a win and what will be considered a fail?
After the conversation, I received a large number of notes and formalized the main ideas in the form of a mindmap (in russian)
Since i had never used our existing web platform, but already had a small idea of what information could be obtained there, i decided to conduct an usability test on myself in order to better understand what a new user is facing while trying to use the current solution.

With a few basic user scenarios in front of me, I walked through each step, asking myself 4 simple questions along the way:
★ What do I see?
★ What do I think?
★ What do I feel?
★ What will I do next?
Current interface of our Web-platform
While researching our current solution I have been carefully inspecting the current design, try to understand how it works and find out the intentions behind each decision. While building the current user flow I was able to identify key problem areas. Those problems ranged from usability issues to visual flows, bugs, inconsistencies, wrong patterns applied, or exotic solutions without any reason. For usability check, I like to rely on ten usability heuristics as a cheat sheet and find out whether the design ticks all boxes.

Ten usability heuristics
Based on all the work done earlier, together with the team, we wrote down several hypotheses of product usage (jobs) that needed to be tested on our final users.

I conducted 7 user interviews in order to validate my insights. Each interview took approximately 30-45 min and included topics to get to the core of what our users are trying to do and what their problems are.

So for each hypotheses I asked the following questions:
★ How do you solve your need now? Are you satisfied?
★ What problem are you trying to solve?
★ What is currently causing inconvenience when using the current product?
★ When was the last time you faced this problem? Describe the situation
Old User Flow translated in english with some comment in english (the original is in russian). Click to enlarge
Thanks to the interviews that were carried out earlier, it became possible to confirm some hypotheses and amend others. Jobs to be done is one of the instruments that allow us to better understand our user's motivations and expectations, empathize with them. People use the persona model a lot, but I'm not a big fan of that approach. In my opinion, personas, are fluffy and often fake which means they have very little practical application.

We realized that there are several key roles with some differences, but for efficiency, it is worth building an MVP based on processes for one role. We decided to prioritize work on one type of user: "The owner".

By building a convenient solution for this role, we kill 2 birds with one stone:
★ A small system that works can be later scaled into a more complex one
★ Receiving funds for the next stages of application development
Few JTBD statements translated in english with some comment in english (the original is in russian). Click to enlarge
We decided to make a mobile application. This way, access to the information you need is always at hand.

Together with the team, we discussed what information are we going to show, what features are going to be our "Low hanging fruits" and what technical issues we can face while implementing our ideas. Considering the context of using the phone, I decided to experiment with the way information is presented and in the process of sketching i came to this solution:
First on paper, I tried to combine the information in a way that it would look more natural and provide a gradual data disclosure if needed, so I suggested a design which won`t have menu bar like there is in our web platform and still will offer information in one click.

My assumption was that it is easier to follow a simple path, especially when there is not a lot of screen space and there is less attention from a user while he uses his phone.

On each step, our users will receive just enough information in order to decide if they want to move forward or they fulfilled their needs.
I had doubts that I had taken into account all the scenarios in the process of rebuilding the information architecture, so I decided to make a paper prototype and run a couple of basic scenarios.

I took some pictures of my sketches, uploaded and linked them. 2 person from our team tested it and they were able to successfully finish our main user scenario.
V 1.0
After reviewing usability testing results, I made some text improvements to make it more clear and grouped the information inside the tables in a slightly different way.

Here comes the funny part. I had made the hi-fidelity prototype in black and white, because I wanted people to focus only on the architecture and the usability, but turned out that everyone actually liked the b&w version so we decided to use it as our final design solution. I just had to add some color to the graphs and to our critical information which required a color focus and those were all the improvements.
I designed the rest of the screens, found a nice pack of illustrations, and adjusted it to our needs. Made sure that we have designed all button states, errors, edge cases, and font use is consistent across all the screens. Right after it, it was time for a new round of usability testing. We presented our app to 4 of our stakeholders and received some positive feedback and a few more features to add/improve.

We had made our usability testing and we saw that the time needed to perform different use cases dropped significantly. From 25% for secondary scenarios to 400% for the main one.
V 1.1
With the results and comments from our last usability test, I was able to make our new version. 2 screens and 1 additional state of the second screen are enough to perform our main user flow:

After a successful login, we get on the dashboard. We can navigate between our projects, platforms, areas and time range for a specific currency. If you want to see how the results were changing from one day to another for a specific currency, you tap on it. On the second screen, we have our graph with detailed numbers for any selected day or period. In case you need more information you dive into details and find reports, and just a bit deeper, transaction history for the selected range.

At the beginning of work, we decided to consider the design successful in the case if the users can go without problems with the basic scenarios. As the last tests have shown, users are successfully passing the scenarios and the time has been reduced by 500% (log in -> view transactions). We have got positive feedback and now continue working on the app, developing new scenarios and new types of users.

As for me, I feel that it was amazing that everyone was open to some brave changes. I guess in terms of communication there is room for improvement. As it was our side project, we all still had to do our main job and because of this, it was sometimes hard to find extra time for one more meeting. I guess once it will become a full-time project for someone, it will be much easier.
Made on