4 ms·

There's a grey area though, where you properly define a new style (yay) at the time the first Cancel button is created, but then down the road you find yourself

There's a grey area though, where you properly define a new style (yay) at the time the first Cancel button is created, but then down the road you find yourself with a whole bunch of new styles for things, and it turns out over time that the styles are maybe repetitious or subtly inconsistent or whatever. The debt has become the reality that the initial abstraction ("all our buttons are the same") hasn't kept pace with the needs of the product as it has iterated forward. Paying down the debt is creating new abstractions and updating all the buttons to be using them. The worst case scenario is probably partial paydowns, where the abstractions get changed but some of the non-aligned stuff remains and so that you end up with a jumble. Especially combined with inadequate documentation (or a culture of inadequate documentation, where people don't even look because they don't expect it to be there), the old practices can end up being cargo culted forward even when someone attempted to create a better way.

milesvp 6y ago
On a slight tangent, my team had very good results when we finally brought a style guide online. Our org was big enough that people would be working on pages without context for the bigger design themes (especially related to sales/marketing). We required any UI variations to be added to the style guide, and we required a minor justification to add styles. This added just enough friction that a lot of the unintended variation went away, and a lot of the variation just to be different became explicit so discussions about the design could be more deliberate.
- imagine99 6y ago
  How did you enforce this style guide, e.g. to make sure that sales cannot simply write a proposal in Tahoma instead of your company font or marketing publishes a newsletter in Arial using underlined words (gasp)? A couple of years ago I had to spend a considerable amount of time PoC'ing platforms and tools claiming to solve this issue and I remember there were virtually none that did this on-prem using established Office programs, without a four to five figure investment. The organisation in question ended up using password-protected Word files with forms (a royal pain). Before that, they had been using Excel files (apparently it's easier there to lock parts of the sheet you don't want users to mess with) but this was an even bigger pain as Excel still has this decade-old bug even in its latest version which distort graphics when row height is changed...). Long story short, I'd be curious how you solved this and what software you used.
  - milesvp 6y ago
    Mostly we enforced it adhoc. It helped that the whole design team was pushing for print standards at the same time. It ended up being a bullet point that needed to be talked about during sprint planning. It helped that designers were part of some of these meetings. If our company had been bigger it would have certainly been more challenging. Mostly we tried to make it part of the culture that we stick to what’s in the style guide. And anything that deviates had a task of adding it to the style guide. I have to say, that I wasn’t completely on board for a long time, since I was sure company culture would make it hard to succeed. We had a champion who got us about 90% of the way there before leaving. But there was enough momentum that another dev managed to bring together the right personalities and solidify the mechanics of dealing with the style guide that it was a no brainer to make it part of the work flow. We used git to store the html and css examples. Made it trivial to copy. And since devs controlled the repo, devs controlled the pull requests as well, and required review just like other PR. It helped that the designers we had/hired were willing to deal with git, even if they had low tech knowledge. I’m not at that job anymore, so I don’t know how long before entropy wins. It’s the type of thing you have to keep tending for it to continue to be useful. But enough process was in place that it will likely continue to be useful for them for several years at least.

milesvp 6y ago

On a slight tangent, my team had very good results when we finally brought a style guide online. Our org was big enough that people would be working on pages without context for the bigger design themes (especially related to sales/marketing). We required any UI variations to be added to the style guide, and we required a minor justification to add styles. This added just enough friction that a lot of the unintended variation went away, and a lot of the variation just to be different became explicit so discussions about the design could be more deliberate.

imagine99 6y ago
How did you enforce this style guide, e.g. to make sure that sales cannot simply write a proposal in Tahoma instead of your company font or marketing publishes a newsletter in Arial using underlined words (gasp)? A couple of years ago I had to spend a considerable amount of time PoC'ing platforms and tools claiming to solve this issue and I remember there were virtually none that did this on-prem using established Office programs, without a four to five figure investment. The organisation in question ended up using password-protected Word files with forms (a royal pain). Before that, they had been using Excel files (apparently it's easier there to lock parts of the sheet you don't want users to mess with) but this was an even bigger pain as Excel still has this decade-old bug even in its latest version which distort graphics when row height is changed...). Long story short, I'd be curious how you solved this and what software you used.
- milesvp 6y ago
  Mostly we enforced it adhoc. It helped that the whole design team was pushing for print standards at the same time. It ended up being a bullet point that needed to be talked about during sprint planning. It helped that designers were part of some of these meetings. If our company had been bigger it would have certainly been more challenging. Mostly we tried to make it part of the culture that we stick to what’s in the style guide. And anything that deviates had a task of adding it to the style guide. I have to say, that I wasn’t completely on board for a long time, since I was sure company culture would make it hard to succeed. We had a champion who got us about 90% of the way there before leaving. But there was enough momentum that another dev managed to bring together the right personalities and solidify the mechanics of dealing with the style guide that it was a no brainer to make it part of the work flow. We used git to store the html and css examples. Made it trivial to copy. And since devs controlled the repo, devs controlled the pull requests as well, and required review just like other PR. It helped that the designers we had/hired were willing to deal with git, even if they had low tech knowledge. I’m not at that job anymore, so I don’t know how long before entropy wins. It’s the type of thing you have to keep tending for it to continue to be useful. But enough process was in place that it will likely continue to be useful for them for several years at least.