If you haven’t seen The Joseph Regenstein Library at the University of Chicago, imagine the most brutalist, block-like building you’ve ever seen.
Then take away half the windows.
The Regenstein is 577,085 gross feet holding 4.5 million books. Its exterior is comprised of limestone slab “modules” each measuring 27 square feet. Its interior is reinforced concrete. And furrow-browed UChicago students.
On the west edge of the Regenstein library site, students pass a bronze Henry Moore memorial that looks like a skull morphed into atomic plume. The memorial marks the exact spot where Enrico Fermi and his team created the first controlled, self-sustaining nuclear reaction (1942).
And you can’t help but think: when the first shovel broke ground in 1967, Fermi’s history was there too. The Regenstein looks bombproof.
On Monday night, this library was on my mind.
As you may know, I’ve been working on a prototype (MVP) for a software product. The ultimate goal of the software is to streamline and improve the development, workflow, and performance of offshore teams.
By Monday night, I’d made some progress. I’d built a well-structured database layer, 4-5 screens, and logic that allowed for cross-screen navigation as well as uploading of audio and video files (including binary storage and commensurate downloading or viewing by other devices).
But, standing at my desk, staring at the screen, I was struck by how heavy and old the nascent software already looked. Heavy and old is generous, actually. The software looked like the Regenstein library’s digital cousin. Brutalist, blocky, and basically the opposite of how software is supposed to be.
To be clear, I don’t have high aesthetic standards. I own 3 pairs of pants. But looking at the software, I knew I couldn’t show it to potential customers. And at the rate I was improving, that would remain true for a long time.
As an aside: the main goal of a prototype/MVP is to learn how potential customers respond to the offering. If the offering is so horrible to behold that those potential customers can’t focus on the functionality, you’re engineering yourself into false negatives.
When software is “horrible to behold,” the horribleness is usually not just an aesthetic thing. It feels aesthetic at a gut level. But it's actually about grokability of the product, and the intuitiveness of the user experience/journey. Poorly placed buttons, poorly conceived information hierarchy (signaled through colors or fonts) impede the user’s ability to navigate and benefit from the backend, no matter how snazzy.
Another way of putting it: software that is poorly designed is harder to use. Software should, at its core, make life easier. So the border between functionality and design is a very blurry one.
Even though I knew all this and was working to improve the design of my MVP, I noticed something odd. The more I attended to the UI (in vain!), the worse my work on the “backend” became. When I tried to work on UI and non-UI at the same time, my brain slowed down, felt scattered. Mixing creative (UI) and analytical (logic/data) activity forced me to switch domains too frequently. And this switching eroded my effectiveness at both.
With these reflections, I devised a new plan: compartmentalize. Do the design/UI work first. Execute the code later. Maybe I could be faster and better at each.
So, in my Monday mood, I clicked-out of Outsystems (the software development platform I’ve been learning and using). My new orientation for the week: design and UI.
I took a few crash courses and began wireframing in earnest. I did my first 3 drafts on printer paper that I taped to the wall.
And then I discovered Sketch and my entire strategy changed. Not just for this week, but for the next several weeks.
Sketch is a design and prototyping tool, similar to Adobe Illustrator. The tool allows you to create device-sized screens (e.g. for ipads, iphones, desktops) and simple layer-to-screen navigation so that you can model software functionality before building full software products.
As luck would have it, a close friend from college bikepacking trips, Heather, happens to be a design and Sketch wizard. So we started talking fonts, spacing, color palettes, and user journeys. Heather nudged me to read an entire article just about choosing font sizes! And, best of all, she gave multiple rounds of feedback on my initial Sketch work.
The real discovery was this: the benefit of starting with design-based thinking (rather than “engineering”) is not beauty or even better UI, the things I was seeking. The real benefit is speed.
And herein lies the main learning/pivot point:
In my original path, I anticipated 1-2 months of MVP development in Outsystems, followed by several months of user testing, demos, and iteration.
I anticipate Sketch, on the other hand, will allow me to run “demos” with the software as early as next week. It won’t be real software. But it will work just as well as real software for customer research and require 1/100th of the time to create or modify along the way.
I can’t emphasize this enough: the benefit of prototyping with wireframes is not that things look prettier. Rather, fast and realistic wireframes force you to think through — and test! — the proposed customer journey in gritty detail before cementing it in slabs of code, brutalist or not.
I’ll keep learning Outsystems. But for the next chunk of time, I’ll be focused on getting demo-able content in front of potential users as soon and often as I can.
P.s. If you’ve ever worked with offshore teams (think: any team located in a nation that’s not your own), I’d love to include you in my prototyping research. Feel free to use this link to sign up for a demo. All feedback is good feedback!