menu

SpecFM

A network of designers and developers making the best podcasts, blogs, and resources for designers and developers.

Channels
# All channels
view-forward
# General
view-forward
# Assemble
view-forward
# Design
view-forward
# Design Details
view-forward
# Design Systems
view-forward
# Developer Tea
view-forward
# Does Not Compute
view-forward
# Fragmented
view-forward
# Framework
view-forward
# Immutable
view-forward
# inspect
view-forward
# Jobs
view-forward
# Layout
view-forward
# Music
view-forward
# Orthogonal
view-forward
# Programming
view-forward
# Reactpodcast
view-forward
# Research
view-forward
# Runtime
view-forward
# show-n-tell
view-forward
# Specifics
view-forward
# Swift Unwrapped
view-forward
# Toolsday
view-forward
# Typography
view-forward
Team

Tips on gracefully migrating current code with new design system?

September 5, 2017 at 2:26pm

Tips on gracefully migrating current code with new design system?

September 5, 2017 at 2:26pm (Edited 3 years ago)
So at work we're getting ready to start using the new design system I've created. The components are created via Angular with HTML/CSS. We of course have an older system in place, but don't have the time to just update our entire app (it's an enterprise sized web & mobile app). We're trying to think of a way to gracefully do this. And I mean, this is EVERYTHING is practically refreshed. Even a new grid system.
We were thinking only new modules use the new system until we can go back and continue replacing the existing ones? Or do it by component across the entire app?
Any advice would be greatly appreciated. Our dev team is brainstorming as well, but figured I'd reach out for any tips too. Thanks!
(Hopefully this thread can be helpful to others who may go through the same thing too).

September 5, 2017 at 3:13pm
Component by component here.
like-fill
2
  • reply
  • like
We are starting to work in Styled-components, and then each new component gets the updated styles. And as needed adjacent components get updated.
  • reply
  • like
It's a difficult transition for sure.
  • reply
  • like

September 6, 2017 at 6:31pm
Yeah, that's what I'm thinking we should do as well. Component by component
  • reply
  • like

September 7, 2017 at 10:47am
Same, component by component while trying to reduce the effects of globally-scoped CSS until it's brought to the absolute possible minimum, preferably gone entirely. 🙃
like-fill
2
  • reply
  • like

September 7, 2017 at 7:16pm
I'm doing this soon. My client's got four years worth of product built on Bootstrap and a big-ass CSS file of overrides and custom stuff. I've already got it to the point that as much legacy code as possible has been removed but at this point there's not much choice except go to all hands on deck for a sprint and completely rewrite everything. It's not glorious work, but it'll be worth it when we're left with a squeaky clean codebase.
like-fill
1
  • reply
  • like
I feel like there's going to be a flood of people going through this process since design systems seem like they're becoming more "main stream" now. Just a guess ¯\_(ツ)_/¯
  • reply
  • like
I spoke with my developers and they wanna do it page by page, not by component. I guess with an enterprise size application, it's a lot more work and slower to go component by component across so many different areas of an app.
  • reply
  • like
I thought component by component would work too but turns out to make that happen each page has to be rewritten to even accept the new components. So we opted for page by page. If possible, first rewrite the structure of the code but keep the same visuals and then change the front end to the new style.
like-fill
1
  • reply
  • like
Yeah looks like we're going to be taking that route Kev
  • reply
  • like