Comment by WorldMaker

The biggest success story I know is Bootstrap. Twitter Designers wanted to unify internal "quick and dirty" admin apps to a simple style, and built it as an external facing "product". With strong enough product documentation and a decent baseline of styles that a lot of developers outside of Twitter were using it for even public websites, internal use is just peer pressure and "everyone else uses it".

Unfortunately most of that lesson isn't generalizable. No matter how much Salesforce wanted Lightning to be the next Bootstrap, it was never going to be the next Bootstrap. That's a tiny niche.

That said, as a developer who has gone through several cycles of designers trying to force me to buy into whatever their latest "company wide" component library will be, there are still lessons from Bootstrap to take away starting with the big one: treat it like a product and a service. Treat the rest of the company like your customers and prepare for dealing with complaints, needs, and desires as customer service.

Some related bullet points:

- You are only as good as your documentation says you are. Documentation should be a priority. Documentation should be accurate and up-to-date.

- Have a compatibility plan. Internal branding changes on a whim, don't take that out on your customers. Find ways to support easier transitions from whatever old styles exist. Find ways to make sure that no matter what changes updates are clean and easy with as little rework as possible. Especially that last part, don't hose your early adopters by making them redo everything for "the real production version". Just like with any product launch, your early adopters can be one of your best marketing tools and you can't point to how much they like using your library if you put them through a ringer of rapid changes and constant update struggles.

- Treat as much of the communication as possible as product marketing. Don't tell developers why they "need" or "must" adopt your central styles, sell them on why they should "want" to. Sell an experience of working with it. Sell the features that they can't get from off the shelf tools or the things they might already be using. Mandates from managers and product staff can sometimes get things done faster than marketing and salesmanship can (assuming managers and product staff have the time and money budgets for it and an "all hands do this"), but it doesn't create lasting buy in (especially if it creates resentment) and it doesn't build lasting trust in your project or team (it can generate the feeling that because managers/product did it this time, they'll do it again when the next branding fad or corporate whim comes to mind and they have an excess of budget).

- An internal branding product is only as good as its reach: Can you support the widest variety of technology stacks inside your company? How far back into legacy apps can you reach?

- Can you support the widest variety of technology stacks inside your company? Too many times I've seen these branding products die in the meetings of trying to crown a "best framework" or "chosen tech stack". As a design team, that should never be your role to tell developers what technology to work with, you need to meet them where they are. (In terms of modern technical suggests, CSS is universal and HTML snippet copy and paste can be easily adapted everywhere; if you need to include interactivity in your comments try for as Vanilla JS as possible. Web Components and micro-frameworks for Web Components such as Lit and FAST can be great tools here with wide reach now.)

- How far back into legacy apps can you reach? There's great reason to not want to support IE11, but if your company's internal users are still spending most of their day in IE Mode in Edge to get "real work done" that's what you need to support. Sometimes it is terrible to build for the true lowest common denominator, but the unfortunate corporate reality is that your lowest common denominator will always reflect your overall success in something like component sharing or internal rebranding. On the other side "even 'Legacy App X', that developers hate working on and try to only touch with a ten foot pole, had an easy time adopting some of the new components" can be a great part of a marketing pitch to other teams.

- Maybe try to start with the lowest common denominator and the hard problems: your early adopters should be complex and legacy and excited to spread the message if you did a great job solving their hard problems in their ugly lowest common denominator parts of the company's tech stack. The easy stuff will follow by peer pressure in those cases. (The reverse is far less likely, the hard apps will scoff at the all the easy ones switching to the new stuff as just fad followers and trend sheep. They've seen it before, they'll see it again, their own apps will still be chugging along with same classically bad styles then too.)

- Document everything like a product for external vendors and cheap consultants and pet open source projects. Treat questions/complaints/concerns/desires/needs like product customer service. (Have customer support tools ready on Day 1.) These two I think are important and bear repeating.

> since they're being forced to

Be careful with wording things that way. "There's currently no competition" and "you have to do it anyway" isn't necessarily a product feature, but possibly a reason to be distrustful.

But yes, ease of use should be easier to sell given a status quo with no competition and no existing easy options.

> I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way.

It's always going to be a hard decision. It can be helpful to bootstrap with the easy projects with simple needs and by volume (raw number of projects) there might be more of them, but when you finally get around to the hard projects you find you didn't prepare enough and need a lot more work, or big rewrites that will upset all your "easy" customers. But, yes, if you start with the hard projects (and those might be by volume the company's largest codebases or user bases) you might see a lot slower progress, a lot slower to get to an "MVP" point, and subsequently a lot slower to establish some of your feedback cycles, but the teams giving you feedback are likely ones that are going to be most appreciative of the hard work, most helpful in helping getting the easy things rock solid while also given you a perspective on the hardest things, and can be indeed be your greatest internal marketers to other teams if they are happy with all of that hard work.

Stroemgren 8 hours ago

Thanks for sharing this. It’s really appreciated.

I’m very much on board with the “thinking it as a product” and I think we’re actually going to be in good position to sell it to other teams since they’re being forced to adhere to common designs - there’s just no help or implementations to get them there. So even if we don’t build something they find as good as their favorite library, we’ll have the upside of being the one that adheres to the design.

I also like your thoughts on “customer support” and I’m considering whether doing hands on help for the teams migrating would also be worth it.

I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way. Starting with easier stuff would allow us to build a foundation, get to the point where the library is actually installed across products, which could help establish some feedback loops. That said, I really like your point about targeting the most legacy apps. As you say, that might create of following of people that appreciate the work and would spread the word.

Reply View 1 reply

WorldMaker 7 hours ago

> since they're being forced to
Be careful with wording things that way. "There's currently no competition" and "you have to do it anyway" isn't necessarily a product feature, but possibly a reason to be distrustful.
But yes, ease of use should be easier to sell given a status quo with no competition and no existing easy options.
> I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way.
It's always going to be a hard decision. It can be helpful to bootstrap with the easy projects with simple needs and by volume (raw number of projects) there might be more of them, but when you finally get around to the hard projects you find you didn't prepare enough and need a lot more work, or big rewrites that will upset all your "easy" customers. But, yes, if you start with the hard projects (and those might be by volume the company's largest codebases or user bases) you might see a lot slower progress, a lot slower to get to an "MVP" point, and subsequently a lot slower to establish some of your feedback cycles, but the teams giving you feedback are likely ones that are going to be most appreciative of the hard work, most helpful in helping getting the easy things rock solid while also given you a perspective on the hardest things, and can be indeed be your greatest internal marketers to other teams if they are happy with all of that hard work.

Reply View | 0 replies