FICO Summer Internship

Product Development — designing an in-house system for client data management

  • Project Type: Summer Internship
  • Duration: January 2018 — April 2018
  • My Role: UX Designer, UX Engineer, Product Developer

Note
Due to legal constraints (very strict NDA) I cannot reveal some information about the product I helped create or my other work in the organization that contain confidential information.

Summary

I worked at FICO [Fair, Isaac and Co.], Ann Arbor from May 2017 - December 2017 as a Product Development Intern. I worked with the Cybersecurity team reporting to the VP of Product Management as part of a 10-member team. My main focus was on developing an in-house data management system that development and support teams used to maintain customer information.

My Role

I was recruited as the only intern for the summer of 2017. The first two weeks of my internship were spent in understanding the various products the company had on their product roster and figuring out the internal workings of the organization and my team as a whole. After that, I was given my goal for the summer.

The Product

I was tasked with designing and developing Admin Tools - an in-house client data management system that the Cybersecurity team used to onboard new customers into the system.

Now

Currently, the way new clients would be onboarded was by having them send their information to an Client Relationship Manager who would then forward that to a mailbox that was monitored by the Cybersecurity team. Upon receipt of the email one of the team members, who was comfortable in SQL, would create a record for that client and add in the product subscriptions that the client wished to subscribe to. This would be done through an INSERT SQL statement. It was viewed as cumbersome and dangerous as it involved adding records directly into production databases. Any modifications in customer information would also be required. Since this was a new team there was no alternative at the time and it was important to have clients onboarded quickly.

Next

The goal was to have this entire process made easier. The team wanted to do away with email, having the customer directly submit their intent to subscribe to a product on the website. This would then get sent to the Cybersecurity team who would validate the data and finally approve or reject the customer based on the data provided. The product roll-out was divided into 3 phases:

I worked only on phase 1 of the project over the course of my time at FICO.

Process

Images courtesy: Makarenko Andrey, lastspark, Sharon Showalter, Konrad Michalik, Maxim Basinski, I Putu Kharismayadi from the Noun Project

User Interviews

I conducted user interviews with developers on the team to see how they entered data into the system. I also watched as they input data into the system recording the order and format in which the various data points were input. I also requested feedback from them - asking them to share with me what they would like to be able to do in a simple manner and more importantly what their dream system would look like.

Personas

Personas were skipped in this specific project because the end users were very clearly known - it was a select group of individuals at FICO who would be using the software. A decision was made to roll-out phases 1 and 2 of this product first and then revisit phase 3 if needed at a later point. Since phase 3 would need customers to enter data themselves, that would need further research which at this point was not viable.

Lo-Fi Protoype

I began work on a lo-fi prototype by sketching workflows for the system. The workflows basically were a run-through of how the system would flow from page-to-page.

System workflow and fields required
Technical system overview sketch

Wireframes:

A sample selection of one of the wireframes I created

Design Decisions

One of the major drawbacks of such a system was that the number of fields that needed to be entered were fairly high in number. In order to reduce some of this effort, we decided to have automated entry for some fields such as date and organization ID by using the user login information to fetch organization ID.

Another design decision made was to make use of modals when editing data. Owing to the use of multiple pages in the application, it was difficult for developers to go back and forth between pages. So, in order to make that flow from editing a record to going back and checking other information, modals were used. Clicking on an entry opened up a modal which allowed developers to edit records and then clicking "Confirm" to close the modal. A highlighted message at the top of the screen would be displayed confirming that the change was saved successfully.

User feedback:

I presented the wireframes and lo-fi pictures to the team in-charge of maintaining the database and sought their feedback. Based on the feedback presented I created a hi-fi prototype of the final product.

Note
The Hi-fi prototype is unavailable for viewing here owing to a very strict NDA.

Product Development

My previous experience in software development and engineering came in handy at this role. After the design of the system we had to physically code it from scratch. Along with my mentor, we worked on crafting the system with Python Flask and SQL Alchemy. While my mentor worked on the back-end using SQL Alchemy I worked on the front-end of the system using Python Flask, HTML and CSS, ensuring that the system was making timely API calls and using caching to make the data recovery and storage more efficient.

Reflection

This project required that I learn a new programming language - Python Flask. The whole project was an amazing experience and taught me to not only design in the real world but also engineer a product after the design. I specifically learned how to apply design principles from an engineering perspective and understood some of the challenges engineers face while designing to specifications. This has helped me become a better designer and also helped me foster meaningful cross-team relationships.