Systems design | Data architecture and flows
Researching and delivering detailed data architectures and flows is part of the process of solving complex design problems. In terms of technology, I go very deep. My work has been adopted as the official architecture spec by development and product management more than once.
Parsable
Parsable is a procedure authoring and management platform. Managers can create detailed, step-by-step instructions for completing standardized procedures (e.g. machine maintenance on a production line). Executors view procedures on their mobile devices and mark steps as they are completed. The completed procedure becomes a source of quality productivity data as well as proof of regulatory compliance.
Incoherent product architecture
The Parsable object model is strictly hierarchical. However, the web interface presented Parsable objects (reference sheets, applets, templates, jobs, and workflows) as peers. New users had no idea how these features related to one another.
Non-standard terminology: For example, in most products, a “template” is typically an element that generates unique instances of itself. In Parsable, a “template” was something added to a job—an object which itself does not have a true template state. A “Duplicate job” function was used to begin a new job instance rather than, say, something called “Start new job”. “Role” meant different things in different processes.
Unclear object states: Parsable objects did not appear to have states that logically corresponded to concepts such as “draft,” “underway,” “approved,” “cancelled,” or “saved.
No role differentiation: A Parsable user can author a procedure (a series of steps), plan jobs that need to be completed, and execute a job on the mobile app. Author, planner, and execution features were scattered throughout the platform and app.
I began by documenting and categorizing every function and field in the existing product.
VIEW FULL ANALYSIS▸
I further simplified the product structure into three primary feature areas—People management, Authoring, and Job Execution. This better aligned with clients’ prior checklist process.
Amazon Kindle e-Reader
I led the Kindle e-Reader UX team and helped bring three generations of Kindles to market—the first Kindle without a hardware keyboard, the first touch Kindle, and the Paperwhite, a model with a backlight.
On-device account creation
Kindles originally shipped pre-provisioned with a data plan and integration with the user’s Amazon account. It was a terrific first-use experience, but it wasn’t sustainable. It also made it more complicated to gift Kindles without accidentally providing access to the wrong Amazon account.
The out-of-box-experience (i.e. OOBE) was about to become far more complicated. As I worked on design I realized development and product management had only considered a few “happy paths” and hadn’t considered possible error states. For example, a successful OOBE required access to at least a WiFi network. What if one wasn’t available? A PM actually asked, “How would that be possible?”
I said, “I’m at Grandma’s at Christmas and she’s given me a Kindle.” Remember, this was 2012—Grandma might well not have had WiFi.
So, my team designed the entire account creation flow, including graceful failure experiences.
VIEW FULL SPEC▸
ACME
I was the product manager and designer for the ACME product suite which consists of a B2B administrative backend, white-label consumer B2C online retail experience, and an iOS point-of-sale and visitor access management app. ACME clients are typically venues such as museums, theaters, and event spaces which host concerts, provide tours, and other activities which draw paying attendees. Clients configure white-labelled ACME Web services to promote events and sell tickets. ACME also provides credit card processing for clients.
Business model not aligned with features
ACME clients sell tickets directly to visitors and via resellers. Some reselling relationships require a B2B2B site while others utilize vouchers which are basically IOUs and involve no immediate cash transactions.
So, I mapped every possible transaction to the technology.
VIEW FULL SPEC▸
Data model update inconsistencies
The ACME platform uses templates to generate instances and series of events, asset management assignments, and dynamic ticketing services. A key use case is to allow clients to edit templates as well as instances of repeating events. Changes might include times, locations, personnel, pricing, and other factors. Clients might want template changes to apply to all generated instances or only to newly-generated instances. Conversely, clients might want changes to an instance to propagate back up to the master template.
However, it wasn’t clear how any of these edits would really propagate through the system.
So, I designed a complete template/instance update model.
VIEW FULL SPEC▸
Avaya
Avaya acquired Traverse Networks for the multi-platform, mobile application suite I had designed. The Traverse mobile applications supported visual voicemail for corporate phone systems before the iPhone introduced the feature for basic telephony providers. The applications also integrated call logs and presence settings.
No systems architect
Avaya’s unified communications strategy required a fully-integrated desktop application for managing email, voicemail, text, call logs, and video. Avaya had completed a detailed set of UI patterns for the app but had done nearly nothing in terms designing and spec’ing functionality. I found that multiple, stove-piped teams had not begun to coordinate in support of a unified communications experience.
So, my team created the technical architecture.
VIEW FULL SPEC▸
Complex call flow modeling
An Avaya user could conceivably receive calls on one or more desktop app clients, their PBX desk phone, their temporary (hoteling) phone, and multiple cell phones simultaneously. Conversely, an Avaya user could send calls via the PBX via the same set of devices.
The development team needed to support every conceivable circumstance but I was certain they were overlooking use cases.
So, my team did the legwork and created a 56-page call flow spec. VIEW FULL SPEC▸