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:
- Wireframes
- Renderings
- Components
- End Result
Wireframes
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.
Renderings
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:
- Concept art
- Character studies
- Pose & Expression reference sheets
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:
- The institutional knowledge of how this process worked before commoditized UI design is fading. I had to sit with the process to remember the specifics of how make renderings that are “just enough”.
- Renderings are the slowest part of the process (for me), and the one that would be easiest to cut.
- Trying to build renderings based on components is back-asswards, especially for a new design framework. Instead, renderings need to inform the components; but they’re separate so you always have the original material to pull from. Star Wars is nothing without Ralph McQuarrie.
Components
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:
- Lookbook for building out the final Standards Manual & component previews
- Phlex to build the components. I want to be careful in my usage, because I genuinely love writing HTML. But Rails is lacking a good answer for how to build & distribute component views across projects
- CSS cascade layers to break out the styling into logical segments
- Not sure what else!
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.
End Result
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!