over 5 years ago from Jean P, Interactive Designer
I am in the position of being, metaphorically speaking, the bridge between a team of visual designers and developers. Making specs of finalized visual designs and hand over the devs. Is it making these specifications as CSS variables an ethical way of doing it and avoid the Zombie Styleguide?
ok, 'metaphorically' stop being a bridge and leave the communication and delivery methods between vd's and devs to themselves. It doesn't makes sense if I decide which car you'd feel most comfortable. Let them decide their own It sounds like you're not the one who've been designing so you shouldn't decide which tool they should use for delivery. It's not about the which, tool. It's about the most useful tool. And that changes and depend on time/project/work flow/ etc
Agreed. If the files are delivered correctly and devs have access to the right tools i.e. Zeplin or Invision Inspect, then I can't see any need for an intermediary. These will automate most of the hard work.
Unless you want the extra work, of course.
I think Jean's an interactive designer, so perhaps they're talking about designing the way it resizes / animates? Zeplin etc doesn't cover that kind of thing.
Edit: nevermind, they're asking about constructing a design system.
At GitLab we export specs with the awesome Sketch Measure plugin and commit them with Git to our Design repository. Each Git commit triggers a script in that repository (i.e. a continuous integration pipeline) which automatically “uploads” the specs to a publicly accessible URL. Here's an example of an exported spec: gitlab-org.gitlab.io/gitlab-design/hosted/pedro/ce%2328916-spec-previews
There are no costs involved and everything is open source. The hosting part uses our GitLab Pages feature. We also use this for hosting/sharing Framer prototypes and static HTML pages. You can read more about it on our Superpowers section. We try to dogfood everything!
+1 for zeplin. Saves an enormous amount of time since the spec & assets are generated from your designs. For more complicated things I would rely on a user flow diagram to show the overal journey + zeplin for the visual details.
To answer your question specifically: Only you and your team know the best technical implementation of a design system. CSS vars can be easily overridden, they might not have browser support you require, you may need fallbacks anyway (like if you tried to use them in @keyframes). If you have a native mobile application, you'll still need another way to consume those variables. You need a good UI engineer or other technical lead to piece this together.
On design-ops more generally: You need to approach it just like any other design project. Your users are primarily designers and engineers, so you need to build a set of tools to help them collaborate and do more meaningful work.
That might mean:
Styleguides, even if completely automated, can still become "zombies." The majority of the work in making design systems is org/process based. You want to change the way designers and engineers work, but if you don't have full support from your team, then the automated styleguide will still go unused.
Hope that helps. Design-ops is sorely needed and I'm always happy to see companies take it on.
Thank you
It sounds like you're working in "Design-Ops". Much like Dev-Ops builds tools that support other developers, you're working on tools to support other designers. There are a number of great design organizations that have entire teams devoted to this role, most notably, Airbnb.
Think of your role as taking the wild and fanciful creations of the visual designers and converting them into a reusable system.
Your job should be in defining individual components and working closely with engineering to make sure each component looks and works as intended.
Most of your specs should focus on the component level. Think Atomic Design.
Also don't be afraid to have a conversation with the designers when they're not being consistent and reusing the components you've specced.
Exactly. I am approaching the Atomic Design method as we speak and defining components and variables with an engineer.
But I am confronted with the same issues as the GE's Prefix Design System in the long run: https://medium.com/ge-design/ges-predix-design-system-8236d47b0891.
We have multiple apps. And an atom has to match and work cross-app.
You are the only one that understands my question as for now. May I ask if you have been in this role before (Design-Ops)? And if yes, what information you have gained from such position that could help others?
Jean, my reading of the article you shared was about the challenge of getting the organization the adopt a design system. Is that your primary challenge?
If so, you'll need to sit down with your managers and ask them for more concrete guidance and support. Evangelizing in a large organization is really difficult and takes years of experience to get good at.
On the issue of keeping things consistent across multiple apps, I recommend borrowing from the version control process that your developers probably use. When a designer wants to use a new pattern, they have to document how it works, and then submit that to you before it can be added to the system. This helps to slow designers down when dreaming up wild new patterns.
Good luck!
Apologies for the stupid question, but is it:
DesignOps = Specing?
Yes and no.
DesignOps is about building and maintaining the tools that a design team needs to work efficiently. One part of that is speccing those tools for developers, but it shouldn't be the biggest part.
Zeplin.io might be the solution: https://zeplin.io/
Figma also has this feature build in, as far as I know.
It's not a one size fits all issue:
1) Ideally the designer and dev are together, and your Sketch library components translate directly to the front-end library on the dev side. In this manner, if you're successful, you should be able to give a dev a WIREFRAME and they reconstruct it with the proper front end components. Your Sketch components are basically reverse engineered "sort of like this" mock-ups. The designer needs to be in-team OR you have a regular culture of demoing stories to the team/designer directly.
or
2) If a designer and developer can't sync-up together regularly (too many devs per designer is often the cause, but also the designer can be away on vacay or some other perfectly legit reason, etc). you can use Zeplin.io — it's a great service. This would work for 1) too, really. It also serves to make sure a designer has their UI measured and properly put together (no 9, 10,11,9 margins allowed here).
It's really up to the designer to facilitate this on the day-to-day level—and for eng management to set the team expectations on what is considered "done". Or else you run the risk of missing the boat, because even in the best Agile environment you have to move on to other initiatives at some point, and that will cause a backlog of design debt.
Have you tried Webflow for a living style guide? Designers can work straight in there with some powerful features like motion. Then devs would just grab the code and plug in the js.
I'm currently using webflow just for that! Mainly as a starting reference while our dev team transitions into a real design system.
This is an interesting idea! Would be nice to see an example if it's possible and at least some parts of the system are public?
Holy Waterfall process...
Just have the designers and devs sit together. Have them use InVision spec or something. That's crazy.
I am Figma user since the beta days, and an evangelist of it, but did not ask anything about software.
Working in a huge company like mine, 1000+, where devs are scattered around the globe you need to set up a design language. And big companies like mine are not keen on switching their process, they just need to ship right now, preferably yesterday and they don't really care how. I am taking the responsibility of setting a design system that I can build and maintain with the others. (see Polaris, Carbon, Atlassian, Nachos - design systems)
The comments in this thread are just the quick fix and they won't work long-term.
I just wanted to hear personal opinion in delivering to devs, and what findings you found in this process.
If the devs work faster with CSS variables in building up a design system rather than showing them a jpeg of how to space things.
And eventually, evolve these CSS Variables into a Design System? Having defined a set of variables defined can keep the design consistent rather than doing it old school by pointing out "XYZ px"on visuals.
First of all we are a digital agency in Hungary, the beginning of a project, we involve the relevant developers in the research-design process. We started weekly designer-development meetings that help understanding. We use figma for wireframe and visual design. This specifided and commented highlighted separately. The other thing, we try to be in same place if any questions are solved immediately.
I work with a team of 6 developers (split between iOS and Android). Since it is easier for 1 person to adapt instead of 6, I try to deliver specs in a way that works for them. Most of our design work is component-based at this point, so I am handing off specs for 1x atomic pieces, not necessarily entire screens. I make the specs in Sketch and use Sketch Measure or a key (agreed upon by the dev team) to denote spacing.
Sometimes I add notes like "60%" for the width of something, since mobile screen sizes aren't absolute. From there, I put the specs into a Google Slides presentation that has all the other specs, notes, mockups, etc for our current release. I link that presentation into JIRA tickets. That way if things change, I can update the spec in one place (instead of digging through tickets). Added bonus: you get a slide deck of everything you changed during each release.
Anything that gets used consistently and often is then moved to an overall style-guide that is hosted on Frontify. In theory, that is where the team would look for longstanding documentation. In reality, a lot of them have printed versions of specs that get referenced often (EX: a breakdown of our text styles).
The developers at my company just work off the sketch file, and ask me if they have any questions. If there are complicated interactions that aren't apparent just by looking at the designs, I'll annotate in the sketch file. It would be the same process with InVision or Zeplin
What do you mean by zombie styleguide?
The “transformation” happens when the styleguide cannot control anymore the entropy of the production. http://thibault.mahe.io/blog/escape-zombie-styleguides.html
another vote here for Figma.
We're about 70 odd people here at my company, and growing all the time.
about half or so are involved in building our own software. The other half would be on the consulting side of the firm. (we build and market our own software, as well as consult on other projects near and far)
there's plenty of times when teams are distributed far and wide and posting jpegs or sending out photoshop docs is just a broken mess of a solution. doesn't matter if you plug it into marvel or some other app to produce specs...
with figma, you can do everything design-wise you would have done previously, but now you can share it easily with everyone...stake-holders, dev teams, etc... they have access to everything, size, colour, shape, images, css, all of it.... it can be the 'one-true-source' of truth for a project....
I'm guessing that you want to deliver designs from Photoshop in which case you could use https://zeplin.io/ as suggested already by other friends or http://www.wuwacorp.com/specking/ (I use it for fine-touching, last edits specs)
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now