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.
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.
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:
- Intended Audience: It is crucial, in my approach, to separate the notion of simply “audience” and “intended audience”. There will always be an echo out to a broader audience, and that should continuously be considered throughout the lifespan of the project and product. Therefore, “intended” allows the entire team to remember that although we have a set agent objective there are still agents our decisions ripple out to and touch.
- Capabilities: This is the not-so-fun part, when teams have to think about entropy and limits. Clients may say “dream big, there is no limit” but there always are. For instance, although any and every idea is possible (so long as it follows the laws of physics) money and time is not infinite. Knowing your limitations allows you to develop a list of capabilities and fence in your solutions to better suit the problem.
- Tone: Branding, tone, and aesthetic are crucial to how a solution will take shape. It is important to consider a client’s personality as this defines how they would guide a user through an experience just as they would their other venues. Tone and aesthetic shapes content and if you are not designing function before form you are putting the impetus on form (the visuals) which creates a superficial and untrustworthy experience.
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 mode of operating results in many advantages:
- Scalability: If you are producing for a wide range of possible renderings (mobile, exhibition kiosk, large format digital, etc.) you will automatically produce scalable art that is not dependent on resolution, default and native object libraries (almost always stale and homogenous), or preconceived notions of usage (all mobile users are right-handed, exhibition spaces are always brightly lit, televisions are always at least 20 feet from the viewer, etc.). When you design to a wide range of possibilities, you design a scalable product that will solve the problem no matter the usage.
- Immortality: Ok, that’s a stretch of the term, I know, but think about the implications of the above advantage. If your designs are wholly scalable, that means it can last longer in the world without needing a drastic tune-up. No matter the deployment, if the design is agnostic to device and juxtaposition then it can be draped over any framework/platform and still solve the problem.
- A maze is a maze, no matter if comprised of corn in a field or ink on a sheet of paper. The comparative experience may be drastically different, but the flow/path a user takes to solve the puzzle is exactly the same between its iterations. This beginning ideation allows for a better product that is not only wholly scalable, but has the opportunity to provide experiences for anyone (no matter their unique situation, permanent or temporary).
- Simplicity usually results when solving for the lowest common denominator. This gives you a better chance of creating an experience that is legible and navigable by the widest audience possible.
- This is a principle that brings many of the philosophies already mentioned together, resulting in better experiences and aesthetic. Let’s use a stereotypical metaphor for this hot-topic term (in the parlance of our time, indeed).
- If not for the integration and consideration of different ideas, practices, traditions, and flavors we would all be eating stale, flavorless bread and potatoes. Diversity helps us fuse different ideas from wildly varying origins into syntactically better outcomes.
- When you are constantly, solely designing in a fixed space (a Sketch iPhone X artboard, for instance) you are producing “inbred” designs, anemic, sickly, and void of the flavor of diversity. Sometimes this is all you can do when designing in a static workflow.
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:
- Develop a Content Strategy that serves the main objectives, brand messaging, and core personas (including the incorporation of the broader, universal audience).
- The Content Strategy will typically nod towards two bends: General & Optimized
- General Information Architecture (IA) is the McMansion of IAs. It’s the pre-packaged, one-size fits all solution. We’re all familiar with these and they are commonly employed precisely because the mass populous is familiar with them. These routes are often picked when a client distrusts the ability of an audience to learn new functionality on the fly, are unwilling to take risks, or are simply trying to cut the fluff and increase conversions (best in ecommerce).
- Optimized IA is a broader solution that can look like anything, but it often breaks the mold of a digital product (i.e., no global navigation in favor of in-page contextual navigation, search only information gathering, etc.). Since this is riskier and harder to acquire definitive test results from most clients favor the general solutions.
Aerospace.org 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.
- Create a core path for content consumption. This usually manifests as a written outline that is shared with the internal team and clients. Continual iteration and refinement outputs the beginning of copy, user experience prototypes (in linear, written format), and template and component needs.
- Pages and their templates, page elements and their components are then defined formally using a spreadsheet that will be continually updated and edited through the lifespan of the design and development process in conjunction with client and internal reviews, and the evolution of the design itself.
- Eventually, when devOps begins this document is then used to create build tickets and their acceptance requirements.
- From the content outlines and the UX flow they naturally propose, I move immediately into user interface design — with short asides for sketching ideas. This workflow specifically consists of in-medium (writing HTML, CSS, JS instead of static composition in a program like Figma or Photoshop) production whenever possible and whenever it makes sense. [Note: When working with a larger team or with client requirements, I use the specific platform/software that benefits the greater majority.] This step concertedly skips the entire visualization stages of wireframing. This has many immensely beneficial advantages including, but not limited to:
- Negating the confusion and time-suck caused by visual-but-not-visual wireframes that naturally and mistakenly prescribe a very restrictive, stuffy visual solution. Stop kidding yourself, they do.
- Providing the full visual experience one expects from the outcome of the entire product build: a product that moves, breathes, and feels like it should on the day it launches.
- Allows for immediate user testing that isn’t limited to pencil smudges, post-it notes getting stuck to unmentionable places, and the frustrated repetition of explaining an interaction for the umpteenth time. / Why test a bulleted list or abstract set of terms when you can actually test the product itself?
- Speeds up production time exponentially by eliminating an entire phase that will already be evolved/addressed in the design phase, anyway.
- Communication is constant with team designers and developers. This means the product is vetted for budget fit and platform feasibility before it is first reviewed by the client. The team should never have to say “I’m not sure, we’ll ask the developer” in a meeting.
- This process also ensures the right questions are asked of the client when reviewing.
- More eyes mean less mistakes and misses. Modular CMS builds, especially, require many variant-based components with varying customizable pieces that make up the whole. Different perspectives bring in ideas an individual could miss.
- In this process, I return back to the persistent Template & Components spreadsheet to keep it updated and ever evolving.
- Bringing engineers into the ideation and design phases can result in ideas designers are too eager to throw out or never fathom.
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.
- Through countless rounds and reviews with the client comes a successfully designed product, and since I was meticulously documenting the requirements for the build from the onset of the project moving to development is seamless and painless.
- A kickoff meeting introduces the devOps team to the prototype. Questions are answered. Bugs in the design are fixed. This kickoff is absolutely crucial as false assumptions can still be made with in-medium designs.
- When everyone is comfortable and happy and the prototypes are understood tickets are generated in conjunction with the project manager. / Typically, a ticket is made for each template, component, and any unique one-off pages and elements. I’ll usually produce an initial “Global Styles” ticket, as well, which includes a thorough stylesheet in-medium that is wholly responsive. This ticket will include all peripheral assets, as well, (favicon, webclip, icon font(s), font file(s) or font CDN provision, etc.).
- Support QA and devOps for refining front-end and quickly turning around solutions to various bugs.
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).
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 😤).