Model N - File Process

process files cover.png


A software product does get complex over time. This tendency is even greater with enterprise/B2B products.

It was a cloud software product that was built and designed by software engineers, for sales people to process and validate files, and that had grown steadily (in size and complexity) over the last 20 years.

As I have learnt, the goal is not "making the complex design simple". Often, trying to force simplicity on inherently complex systems is destructive for end users.

With comprehensive research, methodical planning and careful design, I led efforts to consolidate, restructure, and improve the UI and UX of this SaaS software platform.


  • Users should be able to

    • process files

    • skip one or more processing steps

  • View the status of each process



  • 1 front-end/UX developer

  • various back-end and front-end developers

  • UX Designer (myself)

  • UX Manager


Because our customers mainly come from sales operation of medical technology companies, these products and services can get really complex and extremely configurable. It is important to accurately model all possible configurations so that when the files are actually submitted and validated, an accurate amount of rebate can be offered to their partners companies.


To keep track of progress and develop a point of reference for the redesign project, I set up spreadsheets that would eventually become a comprehensive site map of the entire application. Of course, it wasn’t feasible to map the entire thing at once.

On these spreadsheets, we noted:

  • page flows

  • hierarchy within menu structure

  • important enhancement case stories numbers related to the page

  • breadcrumbs

  • summary of UI elements (forms, grid, types of form fields, instructions text, etc.)

  • a color indication of the current status of the redesign (not done, in process, in testing, complete) for an at-a-glance overview

Screen Shot 2019-01-09 at 8.48.28 PM.png


For each new section that we chose to tackle, I started by conducting research to fully understand its purpose, including:

  • its evolution over time

  • how it was intertwined with other modules

  • how heavily it was used and by whom

  • which problems it solved for our users

  • known problems reported by existing customers

  • enhancement requests related to the module


I always start working on a project by trying to understand “the big picture”, like how a section fits into the product and the overall user workflow. Then I focus on the details, like the purpose and context of each form field or grid column, as well as conditional paths within a flow. After I have a good grasp on both, I’m ready to start ideating potential improvements.

Before jumping into Balsamiq or Sketch, I make a point to spend some time on pen and paper. Sometimes the redesign for a given form or workflow seems obvious based on similar pages that I’ve worked on.

Nevertheless, I always try to challenge myself to explore multiple variations. Often, I uncover unexpected and ultimately successful solutions after spending a bit of time pushing myself to take more risks and think outside the box.

This is so much more effective with the freedom of pen and paper than designing in the browser or playing with combinations of existing symbols in Sketch.

Here, I will focus on showcasing how the Process Files feature was redesigned.


Process Files

Users can do one of the following:

  • Select one or more files to process. Users may choose a different option for individual processing.

  • Unselect one or more of individual processes to make sure that users get to pick and select exactly what they are looking for.

  • Repeat these steps as many times as the user may need to.



As a part of the first step, we, a team consisting of myself (UX Designer) and the Product Manager visited few of our customers to introduce the redesigned product. It was a good thing for the company because few of our customers had questions about why few changes were made from a design perspective and I, being around helped them get answers to those questions. Our visit also gave us an opportunity to get some initial feedback before the release.

Some users complained that the changes were unexpected and confusing. A few users struggled to re-learn how to complete tasks that they were used to doing a specific (albeit convoluted) way.

So for each release (about every 6 weeks), I began compiling “UX release notes”, made available to all users in the software’s support center. This included detailed before/after notes and screenshots of all significant interface and UX changes.

The documents were especially well received by the customer support staff. They used them as an ongoing reference and often sent them directly to users in response to inquiries about the changes.


After we completed the redesign of a few higher-traffic modules, users began to ask in support tickets and training sessions “when will Module XYZ get the new redesign?” It was clear that our changes were making the system more enjoyable and easy-to-use, and in turn making our users more efficient at their work.

The improved user experience of our software was not the only benefit of the redesign. As part of my team’s work, we continually:

  • created templates for reusable components and workflows

  • consolidated multi-step “wizards” into simpler dynamic forms

  • removed unused or duplicate functionality and deprecated files