• UX Research and Design
  • Interaction Design


  • Axure
  • Sketch


  • Research
  • Heuristic evaluation
  • Wireframes


Oranj is a white-labeled wealth management tool. It allows financial advisors to manage their current and prospective clients. Oranj also allows clients to view their aggregated financial information, set up new accounts and financial goals, and communicate with their advisors. Focusing on the client side of the platform, our objective was to research, test, and optimize the existing live product.


I have three banking apps on my phone, one for each bank that I have an account with. I, like many people my age, also have multiple student loans, which don't warrant precious space in my phone’s storage. There’s also a 401k that I’ve never actually checked on. To put it simply, I'm a prime candidate for someone who should be speaking with a financial advisor.

I'm also exactly the kind of person that could benefit from the service that Oranj offers. Being able to see my financial information all in one place, and actively play a role in managing it with the help of a financial advisor, would certainly help me.

Fortunately for me, and possibly you too, Oranj is already a live product. Working as part of a three-person team, I conducted research and testing that resulted in wireframes detailing a redesign for the product. Our project was completed over the course of three, week-long sprints. It was readily accepted and has been incorporated into the most recent product update.


Getting Familiar

I didn’t know what to expect when we first met with Oranj. Short of having signed for some loans, I had very little financial literacy. My general lack of knowledge isn’t uncommon. That’s where Oranj comes in, by improving people’s relationships with their financial advisor.

At the onset of the project, the product existed in minimal viable product (MVP) form and was being rolled out to users.

To get a better understanding of the current state of the MVP, we performed a heuristic evaluation.

After synthesizing our results, we found these notable issues.

  • Breaking down processes into manageable steps.
  • Prioritization and clarification of information.
  • Lack of error prevention.
  • Lack of feedback.
  • The system did not match users’ mental models.
  • Lack of visual affordances.


With a new familiarity with the product, we began domain research and analyzing competitors.

We found that there are two main types of competitors. Traditional advisors, like those at Charles Schwab, utilize standard dashboards and communication with their clients. They help set up accounts and goals but are rarely heard from on more than a quarterly basis. There's also robo-advisors, like Betterment and Jemstep, which have become more popular since the last stock market crash. Their long-term viability is uncertain because they have only existed in times of market growth.

We identified that conveying the sense of security, as well as providing clear, understandable information is very important.

I identified two key opportunities for Oranj to distinguish itself based on areas where the competition was failing. The product could succeed where others aren’t if it,  

  • showed the path to success (larger goals are made up of smaller steps).
  • facilitated communication between clients and advisors for a personalized experience.

How could we redesign Oranj to take advantage of these opportunities?

To help answer this question, we interviewed financial advisors and subject matter experts, as well as people who have a financial advisor.

“Lack of communication is almost always the case for losing a client.”
— Sean C., Financial Advisor

We found that communication is one of the most important parts of every successful relationship. Advisors wanted to help clients focus on goals and achievements while helping educate them about relevant topics.

Users reflected these desires, although they didn’t always recognize them. Issues often came down to financial literacy and awareness. We realized that users didn’t know what they didn’t know.

Along with interviews, we conducted a series of usability tests to gain an understanding of users’ perception of the current platform and assess their ability to complete a series of tasks.


We found points of interest that often stemmed from users’ comprehension of what they were seeing, especially regarding navigation, verbiage, and data presentation.


Using an affinity map, we synthesized everything we had learned. We found key points of interest around goals and progress tracking, information organization, and financial literacy.

To embody our understanding of the user, we created a series of general personas that we could reference throughout the remainder of the project.


Our primary persona, Dave, helped us understand and speak to the importance of accessible communication between clients and their advisors, amongst other critical functions that were translated into our final design.


Putting it together

Having an understanding of the users helped us focus on the problem that needed to be addressed. Dave knew it was important to be on top of his finances, but he needed help. He wasn’t sure if there was anything he was missing, so he went to a financial advisor, but only communicated with him a few times a year.

To say it succinctly,


With the problem defined, the next step was outlining principles that could be used to keep us aligned when solving the goal. Diving back into our research, we drew from what would be important to Dave while using the service.

The design needed to be, 

  • Connective; the system will facilitate a collaborative relationship between the client and advisor.
  • Informative; the system will explain the meaning of the information presented.
  • Personalized; the system will reflect the goals and priorities of the clients.
  • Convenient; the system will provide access to relevant information on demand.
  • Accessible; the system will provide information in a language the client understands.

These helped us say no to numerous ideas. Ultimately, they allowed us to produce a unified design that was focused on the user.


Time for exploration

After presenting our findings to the Oranj team, we began ideating solutions. Crucial to our process, we conducted a “brainstorming day” in collaboration with their team. These were inspired by the Google Ventures Design Sprint activities. Our goal was to generate as many ideas as possible in a concentrated period of time while staying in sync with the client.


Before conducting the activities, we ran our own internal brainstorming to improve our foundational understanding and align our goals. We accomplished this through multiple rounds of “Crazy 8’s” and other rapid ideation activities.


While working with the team at Oranj, we guided activities by pulling from our previous ideas and research to ensure the session was productive. Working with members of their product and development department, customer relations team, and management members allowed us to gain a complete picture of what was important.


Getting in front of users

Working from what I knew to be the client’s priorities and capabilities, as well as addressing Dave's the needs and frustrations, I created a series of screens in Axure to communicate my vision.


Through testing, navigation was identified as one of the main issues users ran into because it existed in too many disconnected locations. To remedy this, I designed a left side menu bar for page navigation and located action items in the title bar at the top right of the screen.

The structure and organization of information was also important for Dave to have the best experience possible. I designed cards with a focus on clear visual hierarchy. The card system also fit well with the client's expressed desire for customizability because it allowed Dave to log in, quickly understand what he was looking at, and reorganize it as he saw fit.

When it came time to test the three prototypes we had generated, my team and I looked at a variety of key areas.

We found that users preferred consistent top navigation because it didn't need to hide information with layers. We also found that users preferred information to be arranged in a loose, or less dense, fashion. This allowed them to gain an understanding of what they were seeing faster, even if they had to scroll to see more.

Regarding communication, having a tab that appeared from the right of every screen tested the best among users.

Based on everything we learned to that point, it was time to converge once more on a final design.


Putting together everything we learned

Considering the nature of Oranj’s content and what we learned from users, we knew consistency was key.

When putting together our final design, we used consistency and addressed multiple issues that were identified.

While using the site, Dave’s communication needs would be meet by having an accessible tab opened from the same location on every page. This would encourage communication with his advisor by making it easier to send and receive messages.

Clear visual hierarchy was also important to emphasize. Making information and data visualizations clear would allow Dave to be informed while reducing the likelihood of misunderstandings.

I created a series of building blocks, based on atomic design principles. This would allow the Oranj team to build and create new pages while maintaining a consistent appearance.

The culmination of this project resulted in responsive wireframes, as well as “atoms and molecules” that could serve as foundational pieces for new content. Accompanying these artifacts was documentation outlining usage, best practices, and further considerations.



After presenting our designs, the client was very happy with our work. Because we were in close communication with them throughout the process, they were able to begin developing and implementing changes to their MVP with ease. An updated version of their product rolled out a few months after this project wrapped up, and already started the process of incorporating our design recommendations.


What I learned

This project was different for me than others I had done in the past. Going into it, I had very little knowledge about the service or domain. Much of what I learned was on the fly, through the project or studying on my own time.

It also emphasized the difference between traditional knowledge gained from desk research, and what I learned from speaking first hand with users. I was able to identify barriers that I didn’t know existed only a short time earlier. Taking the extra time to understand the problem and the people that it affects is something I will aim to do with every project I have the opportunity to take on.