LitPro Design
Aerospace Redesign
CarIq App

Design Process

I've been asked many times how in-medium design and design without wireframing actually works, so this article will hopefully help to clear up the initial confusion behind this product-saving process.

Problem Solving

All projects begin with a problem that needs solving. Many requests make the biggest mistake you could make when creating/redesigning a product: they narrow their audience to a handful of personas (typically one to three). Although the intention is innocent enough, these personas aren’t necessarily a horrible idea, but they should not be the end-all-be-all for requirements.

This isn’t to say that interviews and surveys are useless. This exercise in discovery helps to acquire important requirements for what the client is looking for in the first place. It is absolutely important to keep the results of internal and user interviews as peripheral objectives, however, because “following your heart” often leads to solipsistic, finite, stuffy objectives and ideas.

LiteracyPro Needed a System Everyone Could Use

What happens when your citizen intake desks span across the entirety of America, service a wide range of user abilities and literacy-levels, and consist of thousands of disparate government and private entities all with their own methods, systems, technology, and databases? Naturally, you develop a babel fish. Realistically — since that alien species is merely a figment of Adams' imagination — you create a UX version of a babel fish: a seriously simple, completely open backend system that reads at a 4th grade level, and directs the user every step of the way with the necessary items only.

Inclusive Solutions

The solution should always consider the user in its widest definition and breadth. In this way, we should strive for inclusivity and accessibility no matter the scripted, finite personas, approximated circumstance, or researched use case. Microsoft has written extensively on this subject, making their philosophy open to the public through Inclusive Design. What this brings to the industry is an obvious, yet too often ignored, call-to-arms to unbar the exclusive experiences that riddle our products; allowing everyone complete access to products and not simply the binary, stereotypical ideas of abled and disabled.

In this fashion, I approach the ideation of solution(s) with these core factors:

Device & Technology Agnosticism

Navigation is navigation, no matter the device or juxtaposition of the product itself. Therefore, when I design I design for digital; not “app” or “web” or “kiosk”. Medium, for a designer, should be a small consideration in terms of how they actually solve the flow and overall experience of an object — this isn’t to say that I ignore medium, on the contrary, I strive to know every aspect and detail of the final deliverable whether it is an exhibition booklet or an progressive web app. However, my philosophy as it pertains to design is that the device or object in which an audience consumes the product is merely a peripheral requirement and not a definitive objective.

This does not mean that design ignores engineering. On the contrary! I am a believer in tight communication between design and development. In fact, in my proselytizing of in-medium design, I highly suggest designers know current technology and languages. If not learning how to code then knowing how code is written and rendered visually. This intimate knowledge of the environment is comparable to a print designer knowing how paper is made, how offset printing works, how different inks bond to paper, binding techniques, and how a reader uses the object. There is absolutely no excuse for a digital designer not knowing how to write some HTML & CSS, and at least having a general understanding of JavaScript.

This mode of operating results in many advantages:

Words to Visuals

From the discovery of objectives, audience, limitations, and requirements comes the actual ideation of the product contents and experience. There is no right way to proceed here, and often I change how I work based on the team I am working with or the client I am working for.

A common workflow is as follows: Redesign: Optimized IA in Practice

Aerospace, Inc. surprised our team in 2018 by breaking our expectations of a government policy leadership company with the redesign of their marketing site. In going into this project, we delivered concepts for both a general and optimized solution. The latter would mean Aerospace’s team would need to completely rethink how they publicly communicated online. What we all didn’t realize was that the outreach team had already been communicating in this topics-first way at conventions and conferences for decades, anyway. What appeared at first as a high risk plan naturally lent itself to their core identity.

One App, All Devices, to Rule Your Inventory

CarIQ needed a complex, flexible, and dynamic React Native app that could serve dealerships and rental agencies and their hundreds of vehicles.

Testing & Refining

Now that the product has launched live testing can ensue. If the timeline/budget allowed then initial testing would’ve taken place much sooner in the workflow. No matter, testing live is still applicable through the lifespan of a product and is even benefitted when making use of the original design prototypes as a tertiary platform for user traffic. In a way, this space can be used as the C option in A/B tests. This makes it possible to produce alternative designs on the fly and then have the selected group redirected to the key prototype page(s).

Progressive Optimization

The downfall of many dreams tends to rest in this false idea that the first phase of a product should include everything ideated in discovery and design. What I didn’t cover above is the short phase before UX/UI design where the team (internal and client) run through all of the final “nice to haves” and decide which are best for an initial launch phase and which are best kept for later phases and testing. This is absolutely crucial for a solid product build, as the saying goes: fast, cheap, good — you can only have two. Granted, testing earlier in the workflow can provision for almost all three (NN/g agrees, though they're still vouching for pen+paper testing  😤).