The work I did with Kiran Analytics consisted of three products—Newton, Open Hours Optimization and Position Planning. All help analysts while working with banking clients. All of the products work together to determine the number of employees that should work at a branch at a given hour, the number of customers that come through the branch based on time and day and the tasks employees need to perform.
SCROLL TO SEE STORY
I worked with a group of software engineers, analysts and the company VP to co-design three interwoven products that would be used by analysts in the company.
Within Kiran Analytics, analysts all had their own different working style and software that they used to do their work. Normally, this isn’t a problem. However, if for whatever reason an analyst needs to hand off the project to another team member; the team member is left not only working on an additional project but learning their coworkers system. Best case scenario, the analysts reads through their co-workers files and notes and understands their organization system and continues working with the system they set up. More likely, they read through and understand some of their system and rework it into a system and software that they understand while losing valuable time. Worst case scenario, they don’t understand their coworker's system and have to start from scratch.
Many companies deal with this problem: the difficultly of project hand-off between team members. However, as an analytics company who specializes in optimizing workplaces for efficiency; it’s hardly fitting for them to fall into the same trap. To remedy this inconsistency with their company's mission, they put together a team of software engineers, a UX designer (me), several analysts and the company VP to think of three solutions that analysts would use while working projects.
How Might We...
Minimize the friction in the hand-off process without negatively affecting the work-process of analysts.
Though I worked on three interconnected products, I am going to focus on the design process for Newton since it took the most time and set the design language and functionality of the rest of the products. For example, Newton’s tab motif is used throughout the rest of the products as well. Newton took close to four months to design while Position Planning and Open Hours Optimization took two months.
As a reminder, Newton is internal software which helps analysts determine the number of customers which come through a given bank branch during a specific time and day as well as the activity they are engaged with at the teller (depositing money, cashing a check etc.).
Originally, I worked with one analyst who walked me through their process: from start to finish. In total, I spent three weeks talking with her and walking through her process and took notes on which areas could be improved. This was essential because in order to begin to designing, I needed to understand the intricate process that the analysts went through if I were to redesign it to be more efficient. During this phase we would also design out small sections together before meeting with the entire team about twice a week to validate our designs.
During our bi-weekly meetings, we’d explain what we’d designed and the rest of the team would critique and note areas for improvement. The entire planning process continued on this way up until it was time to start building out wireframes.
**There were approximately 15 screens to design along with the style guide which detailed out UI elements which needed to be consistent throughout the app like drop-downs, tables and modals.
In addition to provide a basic visual representation of the screens for things like buttons, dropdowns, tabs, progress bars and titles—I also included detailed labels of each element on the screen. This was vital since the backend information couldn’t be simply described through graphics. There were some design elements that were too complex to describe without text.
The best example I can give of this complexity was with Scenarios and Subsenarios. A scenario can be described as a sort of “what-if” scenario that analysts can play around with. For example they may create a Scenario where a quarter of the customers are cashing a check. A Subsenarios changes one aspect of the scenario for a deeper “what-if '' scenario. For example an analyst may change the average amount of time that cashing a check takes.
These descriptions of Scenarios and Subsenarios may sound opaque but there was no way to simplify the system without stripping away the necessary complexity that analysts have to deal with while working on a project. Which is the reason we went with labeled wireflows. It worked as a manual to be referred back to by team members no matter what part of the process they were on.
**For privacy reasons, I can’t do an in-depth description of the product, but I will go over key design decisions.
The earliest iteration of the login flow was laid out and labeled in the wireframe/design document. A lot of the functionality still remains in the final version. I continued updating the wireframes as we iterating on the design because it also worked as a design document which laid out all the backend functions. The engineers would get this document as well as the final prototype to help them as they build.
Before entering Newton, there is a login screen which interestingly uses dropdowns, since I wanted to limit the number of options that the user can choose from.
There is the industry dropdown which would have options like "banking" and "retail". Once one option is selected in the dropdown, it will affect all the remaining dropdown options. For example, if "banking" is selected in Industry, then only banking clients will appear in the Client Dropdown. Finally, there is the project dropdown which allows for an analyst to select the specific project they want to work on for the client.
Once in Newton, the analyst is taken to a page which looks like this. It consists of a header, which allows for navigation between projects and different products. Then there is the sidebar which allows for in-product navigation.
The sidebar not only works as a source of navigation from one page to another, but also a checklist. The analysts go through a linear process while working on a project. They input information in the form of CSV files. Then they go through and validate that information to make sure it is correct—the software would flag and highlight information that needs to be reviewed. Then they go through and build different scenarios and visualize those scenarios in the form of graphs. Lastly they export those graphs and scenarios to handoff to the clients.
While they can skip around a little, the one step usually needs to be preceding the previous one. So more than a navigation system, the sidebar acts as a progress checker.
The sidebar is collapsable, which is necessary since when dealing with tables and graphs, analysts need as much screen real estate as possible.
Tables were a design element that was present throughout Newton, Open Hours Optimization and Position Planning. To make the tables consistent, I went through and made a list of every single function that would be needed for each table. Things like hovering, sorting, resizing, and several other functions were consistent throughout the all the products.
This was probably the design element that needed the most thought since a lot of the work analysts do is in tables.
I organized this information on a table called “A Table on Tables.” Then I went through and designed each table, making sure that each was consistent but also didn’t have any functionality that wouldn’t be unnecessary.
Newton, Open Hours Optimization and Position planning were the first UX Projects that I worked on. Before, I'd mostly worked on web development and graphic design—I'd also done one UI redesign in one of my classes.
This was the first project where I was in charge of building out the designs—from start to finish. I made my first wireframes and partook in my first co-design sessions. From there I designed every screen and had to think through all of my decisions to predict possible negative outcomes. I didn't have the opportunity to adjust the design while the products were being built so I couldn't test out my ideas. Instead, during meetings and co-design sessions, I talked with the analysts and engineers and hope they'd find any potential holes in my design.
I also didn't know what process the analysts used while working on a project so I relied on them a lot to tell me what they did and at what point during their process. I would ask a lot of questions because things that seem obvious to them didn't necessarily make sense to me as a designer. I also had to make sure I talked with a wide swathe of analysts about their process because if I only listened to one person, and if their experience didn't reflect the majority of the analysts, then the final product would be useless.
I was also brushing up on my HTML/CSS so I could build out some of the screens as responsive prototypes. It was helpful because with code I could build a more descriptive prototype to show how exactly things would move around and function.
If I had more time, I would have really liked to test out the final product with analysts and see how the product actually functioned.