First Date - Beguiling Engineers to UX
The brilliant engineers brought their new AI application for its first date with user experience. A complex, R&D program that parsed both structured and unstructured data, their eyes were shining with accomplishment. A few workflow tweaks then brought us to a button mysteriously marked “Ad Hoc Query.” The user population? Eighteen-year-old airmen, just out of high school and boot camp.Thus began a 45-minute exploration into what, exactly, that cryptic button was intended to do. We journeyed into the world of ‘inverted indexes’ and other technical capabilities and terms known, then, only by such as these PhD computer scientists and EEs. Down and down we went to discover, discern, and understand each other’s language. A picture finally emerged, which I summarized with this little question, “So, what our little airman does, then, is put some terms into this box, push that button, and gets the sources containing that data?” “Yes!” they proclaimed with triumph at their technical achievement. I gently asked, “Um, could we call it a … ‘Search’?” “Oh no!” The deflation, protests, and nuances of the unique sort of ‘search’ that was ‘ad hoc query’ ensued. I could see their excitement, their dedication, their pride in their work. Most of all, they were seeking to be transparent and honest through the specificity; and I loved them for it. Still, that little airman was my user; he was the heart of my work. A bit of time to tell his story, to help them see his point of view, and came at last to the marvelous conclusion, “Okay! Let’s call it a ... ‘Search.’”
What I learned
Secret Superpowers - UX as Techno Translator
The Intervention Tool was the outcome: a simple click-through tool to help psychologists identify not just that a child is having trouble with, say, a reading task, but specifically why problem is occurring and what to do about it. Little will they ever know that this lovely, five-minute tool all began with a mess of a spreadsheet. Okay, really it was a mess of a data model, but domain experts who authored it didn't know that ... yet. These non-tech folks had a fantastic concept for a decision support tool, amazing connecting information to correlate "subtypes" of learning disabilities, and an armory of interventions that could make a difference in each specific case. With that model, it could have been built as a rapid one-off; but I knew where that would lead: endless, expensive, and painful duplications of what would become a plethora of legacy one-offs, with no rhyme or reason to hold them together, and no way to make that beautiful work truly useful for similar efforts.
Having been deeply trained as the sole UX specialist in defense simulation development projects years before, I knew what they needed to make this work, not just once, but over and over again: abstracted data variables and a relational data model. So I bought some time, started with some simple explanations, and ... introduced a domain specialist to the engineering architect. Understanding what each needed to accomplish was like having a secret superpower to be used for good.
For the first few meetings, I sat in as translator, and have to admit, had a geek fest in translating between the two cultures. Before long, the domain specialist was slinging technology terms, and the engineer was seeing learning disability patterns in the matrix. Together they built a repeatable, reusable data model, database structure; and my UX team created a design language to convey it as a futuristic decision support tool that went beyond anything practitioners had seen before. Beyond the immediately realized fiscal benefits of reuse, this super-power moment in time resulted in development of deep-level expertise on both sides of the aisle, and capabilities which inspired new products and possibilities that could be built quickly and robustly.
What I learned
A Sonnet in Software - Beauty, Design Language, and Constraints
How is a design language like a sonnet? Ask anyone who has tried to write one.
Free verse poetry is, of course, the favorite of every literary, emotion-driven teen. It requires no discipline, only a torrent of free-flowing words, from the gut, the heart, or the mind. Bits of paper and pages of journals had hosted my words, such unfettered forms and sing-song A/B/A/B rhymes over the years. As an exercise in creativity, I set myself the discipline to write in the odd and tightly constrained form of a sonnet. Hemmed in by the odd rhyme ordering and specific number of syllables in each line, I imagined that the outcome would be a dry, throw-away exercise. Yet the poem flowed faster and more powerfully than nearly any effort before. In that few moments it took to take form, I discovered a key to creative endeavor: Pushing creativity through the constraints and building blocks frees up creativity. They focus it, condense it, and magnify what comes through.
On the Q-interactive platform, our team daily experienced this wonder through the magic of a design language. It's hallmarks were fluidity and lightness, agility, clarity, and support. Presentation and interactions were lightweight, flowing, and without ambiguity. Psychological and speech assessments are frequently complex and detailed, with many moving parts for a practitioner to track and capture, all while guiding and observing a child or adult who may be struggling, brilliant, or both. An intentional language of design not only provided a sense of ease before any action was done, but made design and its problem-solving fun for the designers! The building blocks and constraints freed-up the creative mind to dive deeper into interactions that simplified and supported through both consistency and its range of variations.
Write a sonnet in software, and you'll see what I mean.
What I learned