Oh lordy, I have something to talk about with Little CRM! I swear I’m not dead, I’ve been chipping away at the project since the last update. I’ve finished the hardest, most important stage of the design system pipeline: The Rendering Pass.
Here's some sneak peeks!
But what does that mean?
The design system workflow
I've been basing The Practical Framework's workflow on a standard animation pipeline:
These serve the same purpose as storyboards. They let you block out how something behaves in the lowest fidelity possible, so you can experiment, edit, and explore with the lowest cost possible.
I’m going to be using Basalmiq for wireframes & interactive prototypes for those reasons.
This is where The Sketch Vortex trapped me for 5 months. Why Sketch? Because, even with it’s foibles and shortcomings, it’s one of the last Mac-assed Mac Apps left, and they’re still indie.
This is where UI-focused vector apps come in. Sketch, Figma, Affinity, Adobe XD, etc etc. In animation terms, renderings are things like:
They’re essential to guiding the end result, but you don’t use them in the finished shots.
I’m not going to lie: it’s been slow, arduous work, and I’m glad to see this first pass over with.
Which raises the question: why even have the rendering step in the pipeline? A common argument for dropping this step is that your components should be their own renderings: design in the code, have a single source of truth, save time on an entire step.
While there are merits to their argument, and I do agree with in certain scenarios, there is a real cost to this approach that I don’t want to take on with The Practical Framework: it limits what the end result can be.
I’m a big believer that the tools you use impact the decisions you make. If The Practical Framework was "designed in code", everything would be filtered through the lens of what’s currently technically feasible from the outset. One of the reasons I hired Wren was because I specifically wanted the insights & talents of a designer who isn't mired in the design
whims trends of tech over the past decade.
Presently, UI design's optimized for commoditization: the sooner you can convert a rendering to the actual component, the better. This has led to some objectively good advancements like easier ways to pull reference colors, values, and padding. But it also means we’ve created an unhealthy cycle where the renderings need to exactly match the component behavior, which hurts both designers & developers. Designers feel pressured to learn how to use janky prototype effects that never quite work like the demos lead you to believe. And developers don’t sit with the work to think about the edge cases.
And more importantly, you lose the dialogue between designers & developers. Good design comes from constraints, compromises, and folks working together. The process of asking questions like:
“What do you mean with this mockup?”
“Okay, but why can’t we make the select box behave this way?”
“What does the animation feel like? Is it too much?”
is what guides everyone to care about their work and build the necessary rapport! So yeah, I wanted to build that directly into the framework’s pipeline; and I’m glad I did.
It also needed done before anything else, because:
This is fairly straightforward: it’s the building blocks of the framework itself. Continuing the metaphor, this is stuff like 3D models, backgrounds, individual animation cells.
I’ll likely be using:
I’ve started digging into Every Layout as part of this, which is WEIRD. I’ve never really heard anyone talk about CSS the way they do. I’m not entirely convinced, but I see the reasoning and I’m curious.
LittleCRM, of course!
What’s next? Next up will be the stuff I’m very comfortable with: building out the components & implementing the renders! I’ll definitely have more fun stuff to share there soon.
Have any thoughts/questions about the design system, my approach, my Spongebob joke? Let me know!