Categories
public-work

Creating a Custom POS/E-Commerce

Overview

Digitizing a Validation & Ordering Process

I performed interaction design on a platform intended to digitize manual validation and ordering processes for custom products.

The platform had to incorporate

  • the selection of products according to a user’s eligibility,
  • several types of customization,
  • translations for a global audience,
  • the technical affordances of the Clover POS
  • ….

My team included the SME’s in my client’s office, internal IT, and a 3rd party development team.

Goals & Methods Overview

Understand the Environment, Ordering Options, and Logic

I needed to understand the ordering process in detail, all the available product option types, the qualification rules, and the environment where sales took place.

Method: SME Interviews

I spoke with SMEs and began drafting up a journey map as a single asset for all information pertaining to the ordering process.

Ensure Useful & Usable Software

I needed to make sure that the software actually solved the problems that various stakeholders were having, and that it didn’t create more problems in the process.

Method: User Interviews, Prototyping, Demos, Testing

I shared prototypes of the software with internal members and walked through the process.

Obviate Risk of a Very Short Timelines

We had 3 months to produce working software. There was a lot to be careful about.

Method: Constant communication with development, SMEs, and IT

I maintained open communication channels with the development team to ensure they received sufficient technical information; with the SMEs to ensure we were solving the right problems; and with IT to properly incorporate qualification rules.

Now, let’s take a look at some of the work

Define, Analyze, Ideate

Interviewing SMEs

My first interview was with the sponsor. The problem was expensive and persistent. In our initial interviews we covered high level themes like:

  • what were our opportunities for digitization here?
  • how do we see this solution integrating with existing environment?

In addition to:

  • who are the buyers?
  • how do staff presently tend to them?
  • what are some insights and challenges shaping the current process?
  • what are some problems with the current process?
  • how does staff process the orders?

From this meeting, I was able to begin drafting an itinerary of the steps taken during sales process from start to finish.

Buyer-Qualifying Data

Since I was preparing the specifications document for a development quote, I wanted to make sure we had details regarding the qualification criteria, but also details about the database schema used to source these criteria.

I spoke with a prospective vendor regarding the details they wanted, and included them in the specifications document.

One such asset was a table containing the qualification criteria for each product.

From User Journey to Initial Sketches

While continuing to discover more about the workflow, I sketched out the screens and general UI elements that seemed necessary on sheets of paper.

Protyping & Validating

And Then Paper Prototyping

I presented the flows to the SME and we walked through it as they explained what they thought was going on in each screen.

We changed the flow 2-3 times and made numerous valuable notes thanks to the decades of experience presented by the SMEs during this process.

We Change the Flow Based on New Information

Walking through the flow, the SME identified 2 significant issues.

The Changing Lives of Buyers

While qualifications required to purchase certain products didn’t change, buyer’s themselves changed through time. Their names changed, their professional lives changed, and so on. We needed to allow for this flexibility within the flow.

This meant that we needed to allow buyers to enter different names and professional designations for each product they purchased. Originally, these details were entered once in the beginning of the process and used for every product.

In this video, we see users can alter their names and designations as they add products to their cart.
Opening the Door to Identity Fraud

All this flexibility in identity increased the possibility for identity fraud. I wanted to make sure that the digitization process didn’t eliminate the existing barrier of human appraisal preventing this type of fraud from occurring.

When the product information was transferred to a cashier, we made it easy to cross check the names we had on file with the names provided by the buyer for each product.

Designing for Failure

Besides for thinking a lot about about the path we want our buyers to take, we considered the ways they might fail to complete.

Then we designed the system to correct or accommodate these failures.

Increasing the Fidelity with Figma

When the flow and UI appeared largely to have stabilized, I wireframed the results in Figma. I paid particular attention to making sure all necessary elements and critical flows were represented.

Challenges and questions were identified and addressed for the web app’s RFP.

Categories
public-work

Custom ERP & Sales Tool

Description

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.

The Problem

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.

Enhance Relevance

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.

Ensure Usability

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.

System Map

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.

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:

  1. Ideate on design goals for the next stage and reduce the number of considerations per stage.
  2. Focus my attention on creative ideation for actions various users might take in particular situations.
  3. Clarify distinct user permissions for the development team (logged in User U with Permissions P can perform Action A)

Object Map

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.

Pattern Research

Researching Competitors

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.

Sections of the web app such as

  • document and photo management centers,
  • messaging,
  • 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.

Wireframes

Prototype

Surprises

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.

Categories
public-work

Online Community Marketplace

Overview

Designing an Online Marketplace

I was brought in as the interaction designer for an online marketplace where users can exchange favors, offer their skills and experience, and request help.

I was responsible for designing a proof of concept and specifications to define the approximate scope and development estimates.

The team included myself, an account manager, and a 3rd party development team.

Goals & Methods Overview

Designing a Complex System

Understand the Client Vision

I needed to understand the client’s vision for the product.

Method: Client Interviews

I interviewed the client and created a “1 pager” containing a product description, ultimate vision, challenges, and revenue options.

Design for the Same People

I needed to make sure the client and my team had the same set of users in mind.

Method: Persona Creation

Through YouTube videos and online articles, as well as interviews with the client, we were able to create a basic understanding of our primary audience.

Ensure Useful & Usable Software

I needed our flows to be useful and patterns to be familiar.

Method: Competition Research, Demos, Internal Testing, Feedback Sessions

I did first hand research on 2 popular web apps that achieve functionally similar results and documented the findings.

Development Handoff

I needed to ensure we produced the information necessary to produce development estimates.

Method: Regular Development Discussion

I worked regularly with the developers to forward updated information, respond to their latest questions, and document the necessary information.

Now, let’s take a look at some of the work

Define & Ideate

Client Interviews

In the initial client interview, we discussed the concept and its origin story.

Origin stories are really important for brand development and culture building, but they can also provide useful cues and insight into the heart of the original problem and intended audience.

After interviewing the client, I produced a “1-pager” and an initial set of user-stories.

user-stories

Persona Creation

After reviewing the client interview notes, YouTube videos, and articles.

Persona

Big Picture Flows

We needed to instantiate the vision into a concrete system that didn’t contain pernicious loopholes.

I started with how Task Rabbit and UpWork executed a few key flows

  • How users registered
  • How users posted jobs
  • How users found jobs
  • How job details were negotiated and finalized

I recorded a video as I performed these, then enumerated and described details of each step.

enumeration of steps and description

Example: Creating Job Posts

I turned the observations into a minimized version that we could use.

Meanwhile, I considered how we might further reduce the work involved in creating tasks. I returned to this particular topic towards the end of the project and created a 3rd option. Essentially, this concept connected a to-do list (the task creation) to a job board.

The details of the project would be hashed out in a stream with a few custom functions for sharing additional details as needed, as well as setting time/date and cost.

competitor flow

System Diagram

Having checked out the flows from competitors, I was able to define some of the system logic in greater depth. I used this to help create the prototype, to make sure I was not omitting critical logic.

I also noted possible issues, database interactions, and user notifications.

system flow diagram

Protyping & Validating

Making Experiences out of Diagrams

From the system flow diagram, I was able to get a sense of the input requirements at each step, and approximate back-end processes that would need to take place.

These informed the core of the functional elements which would appear on a page.

I used this to design the wireframes and prototype that we’d eventually build upon internally and test with client stakeholders.