Digitizing Sales & Admin Processes
A company that sells assets upwards of several million dollars wanted to digitize all their sales related processes. This meant creating a single portal that encompassed:
- Private Access Catalog of Assets
- Messaging, Surveys, & Email Notifications
- Improved Asset Management Functionality & UX
- Document & Photo Management Centers
- User & Admin Dashboards
- Exhaustive User Roles & Permission System
- Google Analytics Integration
It also had to be completely mobile responsive.
The team consisted of myself, 2 visual designers, and our remote development team.
Outgrowing Boxed Software
Our client was using a boxed version of software which approximated their needs well enough to allow them to operate.
However, they did not own their own data; the platform was not mobile responsive; the platform was very ugly from the buyer side, contra their brand; the platform required numerous workarounds which increased the complexity of their processes.
Goals & Methods Overview
Surface Complex Processes
We needed to understand their business processes in detail and ensure system level cohesiveness.
Method: User Interviews
I spoke with end users and documented their workflows, problems, needs, and expectations.
We had to surface relevant actions for users in a variety of use-cases.
Method: OOUX, User Interviews
I referred to OOUX methodology and created an action inventory and object map prior to UI design. Information for these were also gathered from interviews.
We needed to employ familiar UI design patterns within a relatively complex and mobile responsive portal.
Method: Design Research, User Validation
So I researched functionally similar web apps and refactored them as necessary. These were then demoed or presented to our client end-users and feedback was gathered.
Obviate Critical Risks
It was essential that to minimize and isolate project risks.
Method: Agile & Dual Track UX Process
I initiated 2 primary work streams, one for Research and Validation, another for Production. I will write more about how I structured this project later.
Within each stream, we conducted frequent feedback, demos, user validation, and testing.
Now, let’s take a look at some of the work
Define & Ideate
Definition and ideation occurred regularly during design stages.
Requirements were elicited through focused discussion with the client.
My team and I produced new solutions and reviewed them internally.
Winning ideas were further prototyped, analyzed, and iterated on.
Big Picture Process Diagrams
Getting the big picture allows you to see what’s coming.
Through meetings with a senior analyst, I was able to diagram the business processes we would be digitizing.
The fidelity of this map increased with regular end user discussions and feedback.
I used these to enumerate actions required of pages used within particular use-cases. I documented these in an action inventory.
The idea behind creating this was to lay out both required and additional actions all users would have access to in various screen contexts.
This helped me:
- Ideate on design goals for the next stage and reduce the number of considerations per stage.
- Focus my attention on creative ideation for actions various users might take in particular situations.
- Clarify distinct user permissions for the development team (logged in User U with Permissions P can perform Action A)
Here, I gave the action inventory a visual representation. This format was a simpler visual representation incorporating relationships between objects — whereas the action inventory was simpler to create and edit during the ideation phase.
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
Sections of the web app such as
- document and photo management centers,
- user surveying,
- user and admin dashboards,
- or the exhaustive permissions system,
all have functional corollaries.
For instance, Google has Google Drive, and Facebook has Photo Management.
So I asked myself, how would Google and Facebook address some of these problems.
So I recorded videos of apps as I used them in specific ways relevant to my project, and took screenshots of the parts that I would be referring to frequently.
Protyping & Testing
Weekly Prototyping Sprints
Epics were wireframed or prototyped on a weekly basis. These were shared with my team for review and feedback, and then shared with the client.
What Did We Learn?
I believe generally that if you aren’t surprised at any point in the process, then you didn’t do user discovery.
However, my work on this project was so tightly coupled with end users, that useful insights occurred constantly. Because of this, they were also relatively “small.”
For this reason I have left them out of the presentation and focused on the bigger picture process.