Prevent chaotic scenarios by breaking the process into manageable steps.
A bit of context — how did Agile originate? 🐥
Historically, most software would be created through a process called Waterfall. In environments characterized by high costs, risks, and a limited pool of skilled labor, organizations typically embraced a departmental or specialized structure.
Tasks would be typically divided into individual segments, reminiscent of a factory assembly line. These units, defined by their specific roles, worked in silos, meticulously planning, managing, and executing their tasks. In an era of scarce resources and limited competition, upfront planning was seen as a way to mitigate risks and conserve time, and minimize effort.
In less dynamic, stable environments, this old-school approach was reasonable. However, in today’s rapidly changing world, many of these ideas have become obsolete. To maintain a competitive edge, scaling businesses must focus on time to market (TTM), user engagement proofs of concept (POC), and minimum viable products (MVP). This means that planning for scale, infrastructure challenges, and inventory can be deferred until later.
The software development industry is particularly susceptible to the risk of being outmaneuvered by competitors. This pressure to innovate quickly has fueled the widespread adoption of Agile methodologies, which prioritize outcomes over rigid frameworks.
These optics are even more prevalent in the software development industry. The risk of being beaten to the punch is so overwhelming that doing things differently than others ousts you from the picture before you even start.
Agile Manifesto says it all: value over any method.
Result — drastically shrinking the cycle time. From here we got DevOps, a combination of development, operations, and design, which further streamlined the software development lifecycle. Today, decisions are not solely technical; they transcend into strategic realms. Even Agile teams, though dynamic, rely heavily on automation to avoid disorder, employing methods like automated testing. What once seemed unthinkable — multiple daily deployments per developer — is now the norm.
While this is impressive, the software development environment differs significantly from the design environment. So, what does all this mean for designers?
Handoffs are dead ☠️
For many devs and designers, the handoff process is a dreaded memory, often evoking thoughts of sleepless nights spent wondering whether every edge case was accounted for in the UI-Kit or whether an Adobe XD link had been accidentally overwritten by a careless team member, introducing mayhem in Jira.
The unfortunate fact is that the designer community hasn’t pushed for any emulation of what has happened in the software development world. And what is even more astounding is the fact, that designers were present in the room all the time. Don’t get me wrong — the progress we went through in product design is incredible. Yet, not much has happened since Design Thinking and Double Diamond.
Some things will never get old: cross-functional collaboration spiced up with next-level communication and the introduction of new amazing tools.
But there’s another element — and yes, you probably guessed it — it’s code.
Code, like any text, is incredibly flexible and easy to manipulate. You can track its versions, its changes, store it, share it, and/or update it without much hassle.
However, design is an abstract phenomenon; it cannot sustain itself without a medium of expression. It is rather a process, a creative framework that shapes and refines the medium. In other words, design in a nutshell is a series of design decisions informed by human behavior — driven by ergonomics, cognitive capabilities, and aesthetic responses — that morph into interactions captured in a tangible form. Design is often challenging to articulate and usually involves — and surprisingly to many people — complex emotions.
Unlike code, design is far from being something you can easily manage, track, or update — it’s an evolving and nuanced process that defies simple control.
For a long time, I pondered this conundrum, before finally asking myself a simple question: why not enhance our design process by streamlining deliverables that are essentially code?
The answer to that question takes us by the hand down to the realm of Design Engineering. But knowing something doesn’t necessarily translate into knowing exactly how to achieve it. This is where the Progressive Design Model (PDM) comes into play — a faithful companion to Design Engineering.
Long live Progressive Design Model 👑
Cross-functional collaboration, next-level communication, design systems, and design tokens are already standard in our toolboxes. The future holds even greater promises: automation tools, AI-drive co-pilots, and augmented work environments. They will help streamline repetitive design tasks, while pushing human designers, either into more strategic realms of design or into legends of the past. Fingers crossed, it’s the first thing 😇.
Nevertheless, there’s still an unspoken need for a structured approach to effectively harness the true effects of these tools. Imagine a procedural framework, that would help organize our design landscape, break down workflows into digestible steps, and accelerate the design process. Amazing right?
The north star of such a design workflow framework would be a design that is ideated, produced, presented, reviewed, and released according to the very same agile principles developers have the privilege to implement daily.
I took upon a challenge to think through such a model and have since put it to the test. For now, I call it the Progressive Design Model (PDM), and it’s being implemented to the fullest extent possible within an ongoing project — though, like any new approach, there have been a few bumps along the road to success.
Essential Stages of the Progressive Design Model 🎼
Before breaking down the model into distinct stages, I want to make a few key housekeeping statements.
Blindly following procedure to perfection, no matter the circumstance, is just plain foolish— scarce and meaningful detours and shortcuts are an emanation of a healthy relation to proceduralization;
Design is an iterative process — it is very unlikely to concoct a perfect design on the first try.
Design Bureaucracy should be punished — the procedure is just a subsidiary mechanism to the goals of any development project.
Design won’t fly high without proper planning — like establishing a Definition of Ready (DoR), meaning pre-conditions that must be fulfilled before a piece of design is allowed into an iteration; or having an ironclad Definition of Done (DoD) with a shared understanding of what it means for work to be finished.
I’m only highlighting the importance of DoR and DoD. I won’t delve more into project planning, since this would only make this paper less digestible, and this is the opposite of my intention.
Note that the following paragraphs are written from the perspective of a designer actively engaged with the model. Therefore, descriptions revolve around the acumen of knowledge that such a designer should have after each stage or action taken at that specific moment.
Said stages are:
- Monitoring the Fundamentals 🏠
- Continuous Integration 🏎️
- Continuous Stewardship 🛡️
- Continuous Feedback 💬
- Integration Testing ⭐️
- Continuous Delivery 📦
- User Acceptance Testing/Quality Assurance 👩💻
Stage 1. Monitoring the Fundamentals 🏠
The first stage involves either establishing new design foundations or absorbing existing ones. Sometimes, it’s as simple as digesting documentation for CSS frameworks like TailwindCSS, Bootstrap, etc., other times it requires building everything from the ground up.
Naturally, the more complex the development project, the more sophisticated the underlying design decisions will be, encompassing fundamentals such as grid system, colors, typography, etc.
The outcome of that stage is a designer who assimilates the foundations and grasps the entirety of design decisions and their relation to the future code. This accumulated knowledge of the fundamental design setup should give a designer such a degree of fluency, that along the way each teammate can alter the foundations, so they are a better fit for the project as a whole.
In other words, a designer’s role is to understand and monitor the fundamentals, while being ready to amend them in case future code would benefit from such improvements.
This stage is further divided into 3 branches, which can happen at any given moment, depending on the situation:
- Establishing/Understanding
- Reviewing
- Improving
Stage 2. Continuous Integration 🏎️
A step that essentially boils down to merging inputs from various designers into a shared repository. In terms of the actual design file, all design platforms are inherently built that way — even with real-time collaboration in a single file — Figma being a prime example.
Thus, the design file becomes a unified source of truth, containing all design decisions made during the process. By that, I mean elements, components, colors, layouts, typography, iconography, design language, patterns, variables, etc. — including subsequent tokenization of everything mentioned above.
To explore more about tokens and tokenization processes read this: UI Crux: Reasonable and scalable taxonomy for tokens →
The result of this stage is a designer who continuously contributes to a comprehensive collection of visual representations of design decisions that fuel the development process. Crucially, the closer these visuals created by designers align with the coding realities (standard HTML elements, CSS declarations’ outcomes, postCSS specs, Storybook controls in a testing environment, etc.), the swifter and smoother the development and integration will be.
Stage 3. Continuous Stewardship 🛡️
At this stage, the focus shifts to independent actions carried out by a designer who assumes the role of an architect.
While it may seem counterintuitive — since all designers ‘Monitor the Fundamentals’ — an architect takes on a more strategic and system-level responsibility. Their stewardship mirrors the CI/CD process in software development, where source code is compiled, dependencies are bundled, and reproducibility across environments is ensured.
To put it simply, replace the word “build” with “design”, and you’ll get the idea.
Having an architect tasked with strategizing over the design, and seeing through future code is essential to keep up with the fast-paced way code is being developed while maintaining consistency, compatibility, and quality.
Such a designer is responsible for maintaining shared vocabulary, naming conventions, and methodologies that keep searchability, compactness, consistency, and self-explanation of names and terms used across design and supporting documentation.
To dig deeper into naming conventions, check this out: UI Crux: Naming Conventions & Methodologies for Designers →
Moreover, evolving requirements are another challenge the architect must tackle. They keep both the designers involved as well as the design itself aligned with any potential changes or shifts in understanding the product.
The output of this stage is a designer that controls the inflow of design, its quality, dependencies, compatibility, reproducibility, and consistency across different environments, but also gatekeeping the definition and arrival of new components, their strategic importance, and ultimately keeping the total sum of all design assets under control, whilst being vigilant and responsive to evolving requirements, and sitting at the right table where these conversations happen.
This stage can be subdivided into 2 branches:
- UX branch
- UI branch
— each leaning towards their respective fields of expertise and focus.
Stage 4. Continuous Feedback 💬
This stage is an inherent part of any design process. Giving, receiving, and making sense of the feedback is crucial for a successful iterative process.
The outcome of this stage is a designer meeting with internal and external stakeholders, product owners, developers, and other team members involved in the project to gather feedback. This feedback is then organized, filtered, grouped, analyzed, and acted upon if necessary, and ultimately implemented if transformative to the design.
To learn more about that topic of Feedback, over and beyond what you may find in a Google search, read this article: Design Feedback: How to give great design feedback, and how to receive it →
Stage 5. Integration Testing ⭐️
This is a critical step in the PDM pipeline. When each piece of design lands inside the design file, designers should perform rigorous testing to ensure it performs as expected under different scenarios.
Typically, tests are conducted on small, isolated pieces of designs, but they have to be run in proper contexts. One of the angles of the testing is to validate the behavior and functionality of the design (components, pages, stories) as a whole, detecting any issues that may arise due to the combination of various elements or components.
The outcome of this stage is a designer that employs manual or automated design analysis, assessing the quality, integration assurance, and maintainability of design, considering factors like impact and feasibility. The designer detects potential issues such as design smells, unwanted duplications, and general adherence to the design principles (either general or specific to the project). By identifying these problems early on, designers can make necessary improvements, enhancing the overall quality of the future code.
What is worth highlighting is that by performing code-based testing (e.g., HTML/CSS), issues that might not be caught in design tools like Figma, may be uncovered. Code-based testing usually sheds light on aspects of design that would have been otherwise overlooked.
Stage 6. Continuous Delivery 📦
Continuous Delivery takes traditional design handoff a step further through the usage of design systems, automated tokens extraction, normalization of component variants, theming guardrails, and even code snippets.
There is also room for designers to embed themselves in development tools like GitHub, Bitbucket, MDX, Storybooks, and Chromatics — the domains where developers typically thrive. For instance, Adobe XD has a plugin that integrates directly with VSCode, allowing the creation of UI packages.
I’m just saying, it’s not like these things are going to bite your fingers off the moment you touch them. The proliferation of such tooling in the design world would do wonders for both developers and designers alike.
The outcome of that stage is a designer who through the above-mentioned tools continuously delivers not only mockups, but also systemized documentation, code snippets, design tokens, and possibly UI packages while considering the long-term maintainability of the future code. By doing so, the designer minimizes the time required for developers to implement the code.
Stage 7. User Acceptance Testing/Quality Assurance 👩💻
User Acceptance Testing (UAT) involves validating the software’s functionality, usability, and compatibility with design guidelines and requirements. This stage enables designers to provide feedback and ensures that the software adheres to all design principles.
Ideally, UAT should occur in environments like Storybook or Chromatic, spanning all viewports and stress-testing all breakpoints.
The outcome of this stage is a designer who checks the usually overlooked details like alignment, sizing, spacing, consistency, and length of labels, validates different language or currency variations, and inspects in look for apparent bugs. In this stage, the designer can identify ‘mis-designs’, misfits, or anomalies in real-time, in real-world environments in all viewports.
The Holy Grail — Automation 🏆
The North Star, the Holy Grail of such proceduralization, and the true purpose of its existence is the automation →.
By automating each stage of the pipeline, organizations can accelerate the design process, enhance its quality, and deliver value to end users more frequently.
It is not an overstatement to say that we are at the dawn of a new era in design tools — automation is gaining momentum. New apps and platforms are popping up like mushrooms after a rainy day. Although full automation of all stages isn’t yet possible, it is extremely likely, that this scenario will materialize itself much faster than we think.
Ok, let’s cut the smart talk and get down to business. Below are several design tasks that can already be automated with very decent results:
1. Automated Token Generation
- Deliverable: Consistent design tokens across platforms and teams
- Tools: Supernova, Figma (Token Studio Plugin), Zeroheight
These tools allow designers to create and manage design tokens, ensuring uniformity of design decisions throughout the design system.
For example, during a project where we adopted the Progressive Design Model, we were able to save three months from our development cycle. Before using PDM, routine design tasks like testing and documentation would require a lot of manual input, with stacked back-and-forth between designers and developers. However, by automating tasks such as design token generation and integrating them directly into the codebase, we drastically improved the efficiency of our process.
2. Code Snippets
- Deliverable: Almost direct transfer of design elements into code
- Tools: Figma & VSCode
Visual Studio Code can integrate with Figma to provide real-time code previews by inspecting designs right from VSCode. One of the features creates code suggestion snippets directly based on designs.
When delivering a complex grinding system for the platform, we weren’t about to just toss our design over the wall to Engineering. Oh no — we did everything, testing all scenarios, tweaking each layout, nailing down every edge-case question, and perfecting the grid, like our lives depended on it. By the time we were done, the design wasn’t just solid — it was bulletproof, and the code snippets? Pure perfection. All done with real-time code preview in VSCode.
When we finally handed the layouts to Engineering, you should have seen the looks on their faces during that stand-up. The CSS grid was so immaculate that one of the engineers half-joked, ‘If engineers had fantasies, this would be it.’ They were more than happy to build on top of it.”
In total, we cut the usual time spent on the tasks by about 40%, freeing up resources and giving the team more bandwidth to tackle more urgent tickets.
3. Design Decisions Directly to Code
- Deliverable: Seamless collaboration between designers and developers
- Tools: Supernova, Zeroheight
It boils down to connecting design data to the actual codebase. The outcome is streamlining the development workflow with an automation pipeline with direct input from designers. Supernova supports packages (similar to an npm package, for example) that transform design system data into production code.
4. Component Libraries
- Deliverable: UI Component Catalogue
- Tools: Figma & Storybook
The design add-on for Storybook allows you to embed Figma files alongside your code-based components in Storybook. Meanwhile, the Storybook plugin for Figma will enable you to embed stories alongside your design components in Figma. Ultimately, Storybook for Figma can be used by designers in Design Mode or by developers in Dev Mode.
5. Accessibility Checks
- Deliverable: Accessible designs
- Tools: Figma (Plugin), Deque Axe
These tools can automatically check designs for WCAG accessibility issues, helping designers create good experiences for all users (wink, wink: it would be great to have an analog for APCA).
6. Dev Tools Integration
- Deliverable: Deliver design turned into code directly to the software development platform
- Tools: Supernova
Supernova allows integration and automation of design systems within an existing workflow — GitHub, Azure DevOps, Gitlab, BitBucket, or other customized REST endpoints.
The Unspoken Dream
Automation represents the unspoken dream for many within the design community — a dream of efficiency, accuracy, and seamless workflows. By fully automating every stage in the design pipeline, organizations could radically accelerate the process while enhancing quality and delivering continuous value to end users.
While full automation isn’t quite possible yet, it’s undoubtedly closer than many might think, and new tools are sprouting up at a rapid pace.
Moreover, none of these solutions are perfect, and they’re all gonna let you down at some point. But once you get a hold of yourself and stop getting lost in the maze of algorithms, you’ll be the king of the castle, the top dog — a Design Engineering trooper, focused not on mundane pixel pushing but on new exciting features that overtake your competition.
The Organizational Aspect of PDM
Saying all the above, let’s cut to the chase. So, how has the organizational structure for this PDM test run been laid out? Unfortunately, due to a signed NDA and strict corporate policy, I cannot disclose what the project was exactly about. However, for the purposes of this study, these details are actually not important.
Organizational Readiness
The first and most important thing was to get a blessing from the brass. Since it’s an internal project, getting it was relatively straightforward. Let’s just say it wasn’t a walk in the park, to get everyone on the same page.
Next, as a team, we checked if we had everything to launch and successfully execute everything that had been planned. Furthermore, since this was a big one for us, we also peered with our collective consciousness to, make sure there were no hidden skeletons in the closet, that may disrupt, or god forbid, derail the project completely.
Examining operational readiness involved:
- Design Alignment:
- Shared Vision: Two kick-off events were held to get a clear understanding of the project’s goals, objectives, key outcomes, and clarity on the shared vision of the project.
- Design Principles: An introductory part of the future documentation shared with the team, outlining a unified set of principles and axioms guiding the team’s decisions, and ensuring consistency and cohesiveness of the final outputs.
2. Technical Readiness:
- Tools and Software: The team got access to all necessary software and tools to efficiently complete their tasks. Figma, VSCode, Storybook.
- Technical Knowledge: All designers before the launch of the project got access to crucial knowledge sources: https://uicrux.com, and https://mobbin.com, among others, ensuring that everyone had the technical skills required to implement their designs effectively.
3. Resource Allocation:
- Time and Budget: We developed capacity and prioritization plans, set milestones, and created a roadmap with tangible deadlines. Financial resources were allocated appropriately to meet the project’s needs.
- Team Structure: Four new hires were brought on board to ensure that the design team was sufficiently staffed. Moreover, we assigned specific roles to people with the necessary expertise, so they could drive the project consistency and ensure cohesiveness in the final deliverables.
4. Communication and Collaboration:
- Clear Communication: Separate communication channels were established to foster an open and transparent flow and exchange of information.
- Collaboration: Effective collaboration was recognized as essential to keeping the design process efficient and productive.
5. Testing and Feedback:
- User Testing: Guidelines for testing alongside DoR, DoD, and UAT checklists were put in place.
- Internal Reviews: Regular ceremonies including retrospectives were scheduled for the squads to help identify potential issues and ensure that the project stayed on track with its objectives.
Finally, we enlisted a seasoned scrum master to join our team as a Design Operations SME (Design Producer), well-versed in Jira. The new Design Producer ensures the team stays aligned and iterates quickly to meet rapidly evolving requirements, while guiding us through the complexities of design operations.
Workflow Process
Once everyone was on board and aligned, we set up organizational scaffolding that came together perfectly with all stages of PDM.
- Roles
A specific role has been assigned to each designer.
A peer — a designer navigating the project’s day-to-day design tasks, and grinding through tickets. Their main tasks are ideation, research, testing, and iterative design. They are also involved in performing the art of peer-to-peer reviews — an amazing chance to share wisdom and experience.
The peer is a design-driven explorer delving into a vast ocean of product development, and ensuring a smooth voyage for himself and others on board.
An architect — a designer, on top of peer designer’s responsibilities is steering the project through the ever-changing waters of requirements and ensuring a smooth sailing journey for all team. They maintain standardization, manage dependencies, and ensure governance throughout the project.
The architect acts as the gatekeeper, the strategic overseer, ensuring that only the best, most consistent, and future-proof ideas make it through.
2. Ceremonies (Two-week Cycles)
The aim of applying sprint tactics was to foster a culture of continuous design, integration testing, and continuous delivery. Our Progressive Design Model game plan looked like this:
- Sprint Planning (Every 2nd Monday)
- Architect Sessions (Every Thursday)
- Refinement (Every 2nd Wednesday)
- Retrospective (Every 4th Friday)
As a perky byproduct, designers are getting a free ticket for an honorary scrum run, gaining valuable insights and first-hand experience of the good, the bad, and the ugly of the software developers' ways of working.
Summary 😎
Wrapping up and putting in place a brief summary, it needs to be said, that although at first glance it may look like such proceduralization is an over-complication, seasoned designers will likely agree, that it is not an unusual scenario when complex products’ usability gets direct hit or even it gets completely off the rails when proper processes are not in place.
When design operations turn into a free-for-all, it’s like opening the gate of cross-functional collaboration hell.
And yes, effective communication is unquestionably the most important thing, but it is critical to realize that even the best-intentioned talks can fall short if there’s no suitable process guiding the project.
Imagine you are tackling a project characterized by:
- diverse contexts,
- technical and non-technical dependencies,
- with a high degree of adaptability,
- where it is essential to mind technical and business constraints,
- take notice of various factors,
- and large scope involved.
Dealing with a project that ticks at least two of these boxes without a process or strategic outlook in place, it’s like attempting to explore a huge, foreign territory without a map. You might finally find your way, but be sure that, like a good cake is stuffed with raisins, the journey will be fraught with detours, delays, and unneeded obstacles.
The Progressive Design Model (PDM) is a proceduralistic approach to prevent these ungodly scenarios, by embracing an iterative design process divided into manageable steps. All for the sake of allowing for continuous refinement based on feedback and evolving requirements, whilst covering it with a fabric of well-defined governance with a clear division of responsibilities and checks and balances.
If you want to dive deeper…
Here are some articles on Design Engineering that are directly connected to the topics covered here. Go check them out:
- Agile methodology: an overview
- The role of DevOps in UX/UI design
- UI Crux: Reasonable and scalable design taxonomy for tokens
- UI Crux: Naming Conventions & Methodologies for Designers
- Design Feedback: How to give, receive and make sense of design feedback receive it
If you’re interested in a different angle on the methodologies discussed here, here’s some further reading:
Lastly, for those interested in Design Engineering, visit UI Crux: A dev-centric platform for designers, where you can learn CSS and other powerful stuff.
UI Crux – Dev-centric resource platform for Designers
Time for a more progressive design model was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
Leave a Reply