New American Funding

“Sergi has the ability to make complex visions a reality with his astounding attention to detail when creating mocks, wires, and other UX-oriented features.” – Max Graef, Sr. Licensing Specialist at New American Funding

Location Management Tool


The Location Management System (LMS), a responsive web application, serves 2 purposes – it’s a tool for showcasing New American Funding’s impressive database, technology and scale to investors; and it’s a content management system for employees to manage that database.

the map


Rick, our CEO, was at a Knicks game, doing an off-the-cuff demo of our past branch management tool for the CEO of Quicken. During the demo, the app became sluggish and displayed erroneous data.

Rick asked us to solve the problem: fix the data and improve the performance of this product.

Journey Mapping

The director of development, along with various department heads, realized that the data was wrong for multiple reasons – the code base had been neglected, the data was not being maintained or input, and the product had not scaled well as the company grew.

The problem seemed insurmountable: how could we get so many users from so many different departments to collaborate on getting the data input correctly?

I proposed we build a journey map by putting up large pieces of craft paper along our largest wall and inviting all the stakeholders in the process to mark it up collaboratively. I explained that the UI would reveal itself only after we’d devised a complete understanding of how all the different departments and individuals in those departments contributed to the flow of information.

Journey Mapping
Journey mapping an extremely complex work flow helped everyone get a wholistic view of the process.

The Evolution of a CMS

The map was broken in part because users were not maintaining or updating the data.

What we learned from our journey mapping was that there currently existed many different collection points to gather the same data – some pages having been retired but not removed; others having been outgrown by some departments but not by other departments.

Our solution: we realized that rather than re-factoring the broken intranet pages and flow, we had to build a slim, standalone application – which would empower those users responsible for creating, editing and maintaining the data. This system might integrate into the company CMS down-the-road, but for now we’d rather not be tied by that system’s technology, giving us free reign to explore more cutting edge technologies in this standalone product.

Notifications & Easy Add-a-Branch
For me, it became paramount that we make it very quick and easy for the users to input their data:

  • they should not have to mess with other department’s content
  • they should know when it is their turn to jump in and complete their portion of the data input.

As a result of these 2 goals, I designed notifications to be part of the application. And we created user roles to protect data and create accountability.

notif page wires
This wire was marked up during a collaborative session with the team. It’s evolved from notifications into a feed with filters.
Location Detail Template
A hi fidelity mock of the Location Detail Template, reflecting the 7 tabs that create accountability for each department.

Adding Locations to the Map

The MVP of this product is the location creation process. A specific user must be able to create a location – at which point all other users can jump in and comply with their responsibilities of inputting data relevant to that location.

From our journey map, and follow up ux research, we learned that the IT department preceded all others for triggering a branch creation. As we reviewed, iterated and tested, we came to see that the minimal requirement for getting a new location into the business flow was simply the branch name. All other criteria, such as address and branch manager could be added later in the work flow.

add a branch - b vs final
The more we researched and tested, the more concise this step in the MVP flow became.

Blockframing the List View Segmented Controller

Several months into the project, I found that the team was still struggling with my concept of providing a list view as an alternative to a map view. I was inspired by the design of Apple’s old ecommerce pages (grid vs list).

Finally, to communicate my concept and get buy-in, I blockframed the design and presented the concept in 3 short videos. Within 5 minutes, I had team buy-in. Our 1-hour meeting was completed in 5 minutes. Phew!

blockframe - list
Blockframing removed distractions so we could focus on the navigation and interaction design.

User Interviews

I was fortunate in that I would get to interview the primary users of our product. For example, there is a stakeholder whom is responsible for IT setup at each location – that is, he needs to be sure a new location has an internet connection, printers, etc.

IT spreadsheet
meeting the use’rs needs in a web ui

User Feedback

Once I had the wireframes created for each of the departments’ tabs, we reviewed them with those departments. The feedback allowed us to make such changes as making nearly all the HR content read-only. This was important because the HR tab ended up housing a piece of global content – an email tool with universal read-write permissions – and we didn’t want to give everybody the ability to edit the HR content, so their read-only content worked in our favor.

Additionally, the facilities department ended up purchasing a specific software that would expose its data in an API that the facilities page would consume.

User Testing

Defining the filters for the Map/List views required user input. By presenting options to the various user types by walking them through an interactive prototype, I was able to whittle down what filters seemed necessary and how their needs would effect the behavior of our UI.

user research
A slide from my deck, which I used to communicate my user testing findings to the team.


There were times when we made the mistake of doing high fidelity designs before exploring the problem with wireframes and prototypes. These were difficult moments for the team, as we found ourselves drawn to the aesthetic and feeling it would be a pity to destroy it. To draw attention to the problems and get us out of discussing layout, I had to do a considerable amount of side-conferencing with my colleagues – away from the pressure of being in a meeting. These small conversations paid dividends, as we’d be in meetings and I wouldn’t surprise people with my questions or critiques – and the discussion would emanate from a point of comfort rather than stress.


This project reflected a new way of working for the development team. It provided me with the opportunity to emphasize flow, as defined by our users needs. Before development got started, I conducted extensive design research, all of it being kicked off by journey mapping sessions. Then, during the iterative development process, I had ample opportunities to bring the conversation back to our user’s needs – both of the CEOs and the team that would be maintaining and updating the data.