Custom Mobile Responsive Web App to Digitize Asset Sales & Processes

A company selling assets upwards of several million dollars wanted to digitize all their asset management and sales related processes. We designed a platform for their sales team, analysts, and global buyers.


On This project I was both the client facing UX Designer and Project Manager.

In Section 1, I write a bit on how I managed the project as the Project Manager.
In Section 2, I overview what I did as a UX Designer.

Section 1: Project Managing using Dual Track UX

Concurrent Research, Design, & Development Sprints

Retire Risk Early

Before the first sprint, I had about 2 weeks to identify project risks an challenges.

I always like to “retiring risk early” and with the help of the development team, we identified the biggest risk pertained to the complex database we needed to work with, which contained no documentation.

We decided to review user interactions with the database as part of our first line of work.

Higher Development Risk, Lower UX Risk

For us, this meant focusing on the various Asset pages. These were essentially product page variations. 

These required less UX research as we had SMEs and Sales Analysts on hand to provide us with plenty of detailed input. Working on these pages also afforded myself time to work out the broader system.

The chronology of work thereafter was an ongoing compromise between development, client, and UX needs.

Project Management Process

Referring to our backlog, I selected work at least 3 weeks ahead of developers. I reviewed and researched the system level requirements and began diagramming and wireframing possible solutions.

These solutions were wireframed or prototyped and tested with my internal team and SMEs. Approved work was moved into a design sprint, and finally into development and QA. 

The development backlog was organized by the development team, and I reviewed it daily to make sure they were not blocked. I also performed regular UAT on completed items.

Ultimately I was overseeing 3-4 concurrent sprints, while contributing to my own with regard to UX research and flow creation.

Ongoing Client Inclusion

All deliverables were iterated on. After reviewing deliverables for my client, I organized focused feedback sessions with them. Sometimes I looped in a team member first.

Either before or during these sessions, stakeholders would review wireframes and describe what they were looking at or they would interact with a prototype.

The feedback from these sessions would come to inform everything from technical details to user flow improvements. We walked through the scenarios and asked various questions.

For example, we sought to understand:

  • The nuances of approvals
  • The nuances of permissions
  • Most common actions
  • Most critical actions
  • Contexts of various actions

Section 2: Design Process


Documenting the Knowns

The process workflow to the left served as the high-level basis for further UX research and development. I proceeded to break this down into more detail, and created additional artefacts such as an action inventory, a UX object map, and other technical assets.



Action Inventory

The idea behind creating this was to lay out the possible and required actions all users would have access to in various screen contexts. Eg: "For all Objects that are Recipes, members can: Share, repost, copy/fork, add notes for a journal, etc" 

This helped me:
Isolate and focus on the actions that users could take on objects, independent of screens and flows. A very 'blue sky' approach to imagining what one might want to do on the platform.

This also allowed us to focus our attention wherever it was necessary in later stages, rather than trying to collapse thinking about CTAs, flows, or layouts into a single step.


Object Map

Here I outlined the required objects and their corresponding actions for myself and the development team. I referred to this when making wireframes and user-flows later on. It defined the major parts of the website and the corresponding user actions.

As I made these, I shared them with development to gain any possible insight on limitations or possible opportunities. Meanwhile, I discussed these with our technical project manager in Russia to help him being understanding the high-level requirements. Later in the project, I used our combined insights to help inform the chronology of my work.

As noted in Project Management Portion of this post, we decided to begin with “single asset” and “asset portfolios.” This would:

Let the development team start familiarizing themselves with the client’s database early.
Buy me time to perform additional design pattern research and validation, while also seeking out further risks.

Researching Design Patterns for Interaction Design

when a user want to access and organize files, how should that all work?

Competitor Design Patterns

In this project, I was not able to study competitor software. This would have been hard to find and acquire for our purposes. Instead, I continued to refer to our required business process map and sought out functionally related design patterns.

Functionally Related Design Patterns

Some aspects of the platform were relatively complex design challenges, such as the document and photo management centers, admin functions, and analytics areas. Especially on mobile devices. I looked into other web apps for insight on how these interactions worked on desktop and mobile devices.

For instance, Google Drive and Facebook Photo Management on mobile and desktop devices.


Testing & Validation with Wireframes and Prototypes

The project was initially wireframed in Balsamiq for speed’s sake. Later it was wireframed in Adobe XD in order to validate and better test some of the key functionality and flows.

Other members of my team who were not working on this project, were incorporated weekly to experience the flows first hand.

The 3 columns below are a few examples of Balsamiq wireframes. The screenshot at the bottom was taken from the Adobe XD prototype.


Visual Design

The visual design was performed in our Chicago office. I worked with 2 visual designers.

They were made familiar with the company’s aesthetic and style guides by reviewing the existing website, along with a questionnaire every client fills out prior to the launch of any project.

The first visual designs were reviewed by my self and our internal team, then presented to the client. After the general direction had been determine, we sent a batch of designs and continued this every week as per the sprint release cadence.