Time for a more progressive design model

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:

1. Establishing/Understanding
2. Reviewing
3. 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:

1. UX branch
2. 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 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.

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:

1. 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.

1. 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.

Here are some articles on Design Engineering that are directly connected to the topics covered here. Go check them out:

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.