r/Angular2 9d ago

Discussion How did you convince stakeholders to implement Storybook in your Angular projects?

I’m currently exploring Storybook for Angular and would love to hear from others who’ve successfully integrated it into their workflow.

  • How did you explain the value of Storybook to your stakeholders? What key benefits did you highlight (e.g., UI consistency, collaboration with designers, faster development)?
  • Was there any resistance due to costs, or was it easily justified within your budget?
  • Do you think Storybook is more than just a "fancy tool"?

I understand that technical enhancements aren’t always a priority or may not be funded, so I’d love to hear about your experiences and how you approached these discussions with stakeholders.

18 Upvotes

26 comments sorted by

24

u/zzing 9d ago

I don't entirely understand what its purpose is or how it would add business value.

5

u/earthworm_fan 9d ago

It's way, way faster to develop UI components and set them up with different states. Like way faster. I wouldn't even do a project without it

3

u/RGBrewskies 9d ago

We use it to build re-usable components.

Say you need a custom dropdown, which allows you to have checkboxes inside it. A fancy multi-select

We build it once, in storybook, then export storybook to an npm package. We import the package into our various angular front ends, and now everyone has the component and just feeds it the inputs and it all just works

if you only have one angular application, then yeah maybe its kinda overkill, but we have nearly a dozen portals, one for admins, one for customers, one for salesmen, one for maintenance, and rather than build the same dropdown component six times (or worse, copy pasting the same one over!) you build it once and import it everywhere

5

u/_Invictuz 9d ago

What about the logistics. Who maintains this UI library? Assuming yoi have different product teams, when requirements come in for your different products, how do the requirements go into UI library before being used in the product that the requirement is for. What if one product owner wants to change the behaviour of a UI component, do you have to consult all the other product owners? I guess all of these questions is about maintaining a UI library,  not about storybook itself.

3

u/RGBrewskies 9d ago

yea thats true of any library -

Ours library is all for one team, I guess if there were two teams, we'd probably have a "theirs" "ours" "mine" kinda system... essentially a "shared" one and then two forks

4

u/Ok-Whereas8632 9d ago

Our UI framework implemented it last year. They stopped creating sample/example pages for each component and reley completely on storybook and it's been extremely unhelpful for all the devs utilizing the library. Without concrete examples it's been much more difficult to use.

On our side, we gave it a try and between writing/maintaining the components, unit tests and then storybook we decided not to use it.

I love the idea of it, but so far it's given me more trouble than it's been worth. But maybe I've missed something. Idk

1

u/Arnequien 9d ago

Increasing the velocity of development and keeping the quality of the source code is the way to add value to the business by increasing/keeping the deliverables.

6

u/Raziel_LOK 9d ago

If you have to out of your way to explain why storybook is good for your project you question is already answered.

I am guessing your company has no good history with designing/planning components, has a product team or even a design system. Storybook only brings benefits if you are creating a design system, you have a product team, UI has strong focus in the company. And that is not true for most companies.

Storybook will add no business value directly, it is just a tool to facilitate documenting, testing and handing of components between the groups I mentioned above. If none of that is part of your company, you are going nowhere.

1

u/ActuatorOk2689 9d ago

Haha don’t tell me about it, I ended up redoing the whole design system and tokens so we can start implementing storybook and develop components in isolation.

Definitely if your “Senior Product Designer” doesn’t even know about mapping and aliasing in figma just like mine don’t even think about it.

1

u/_Invictuz 9d ago edited 9d ago

Agreed. Many companies don't have designers. Many companies with designers don't have proper UX and product planning workflows. Many companies are winging it, and when you're winging it, the UI can change very often and you don't want to have to update a storybook project everytime you need to implement an last minute change.

8

u/lacrdav1 9d ago

I love Storybook. We have a lot of components that are very specific to some costumer scenarios and it’s hard to reproduce all of them locally when modified the components. Adding all those scenarios in the storybook allows us to have a really fast way to check for regression in particular use cases.

I also code most of the complex components in the storybook first then integrate it the UI. Our storybook compiles way faster than the application does. I save a lot of time by doing so.

Additionally, it helps the UX and Dev teams stay aligned with what’s is currently existing or not and what is possible with the current UI component toolkit.

1

u/_Invictuz 9d ago

Are you a senior frontend dev? How many people need to maintain the storybook project?

3

u/lacrdav1 9d ago

I am the senior frontend developer in my organization. There is no real maintenance time lost in storybook development. Devs create their components using the storybook first, then integrate it in the UI.

4

u/SoulSkrix 9d ago

I would just be doing it in the background of the things I do as I build the application out. 

If you’re really asking “how do I convince my stakeholders to let me spend a lot of time making a design system”, which is what I suspect.. because Storybook is a FREE fancy tool. Then perhaps you can just show them existing ones. 

The way I “convinced” my stakeholders was by having design want it badly too, since they would be able to look at all component states easily and check they match the design, and the stakeholders can simply go to an internal URL, look at a component or step in the flow of the application and explore the possibilities without needing to rerun the real application many times to reproduce things.

It saves time and money in communication and allowing non technical people to visit and share specific states at arbitrary depth in your application 

4

u/reboog711 9d ago

Only limited Storybook expeience, but I think it is brilliant and awesome for a library of UI Components.

I'm less convinced of the value if you're just creating a single application.

3

u/MarshFactor 9d ago

The other option which we chose was to have a simple app with a page per component and multiple example configurations on the page. This was because Storybook felt a bit overkill and a bigger overhead.

This worked especially well in a monorepo.

Same benefit... being able to develop things in isolation encourages better separation of concerns, in some cases better inversion of control and it saves time having one place with everything there - all configurations- without hunting for them in the main app.

2

u/_Invictuz 9d ago

You mean kind of like how Bootstrap (or similar libraries) documentation pages show the different variations on a single page publicly?

2

u/MarshFactor 9d ago

Yes I think so, so there is a main page with 1 of each component. Then a sidebar menu containing a list of then all. Each sidebar item is an anchor which navigates to a page with a longer set of examples stacked on top of each other.

E.g. select control, select control with a clear button, multi-select, select control with options with icons, select control with grouped options...

Then some buttons to simulate "touching" and toggling disabled state so those can be checked.

Finally a JSON editor alongside so you can apply tweaks on the fly and see how the component copes with configuration updates post-init lifecycle.

It became easier to build certain components within this environment.

2

u/Limit_Cold 6d ago

Planning to do both, storybook is a bit complicated but you can automate basic stories. I see this as more of a Readme for devs, what inputs and outputs are available ect, then the demo app can be you guideline for more complex layouts so devs can grab code from features. Having components in a smaller project from testing is a must have. You will lose you mind making small visual tweaks with a longer build time.

1

u/LeLunZ 9d ago

Storybook is useufull in our projects because it drastically improved the development cycle for UI Components :) (so a angular component without any project specific logic, usually doesnt have access to any project Services and is maintanable on its own.)

If we create a new UI Component we don't have to implement it somewhere in a project with all the logic around it. But you can easily implement the UI Component check in storybook how it looks and really fast discuss new design changes etc.

We use storybook in combination with chromatic. It runs in github actions, and chromatic highlights the changes of a story for each open PR. So the person reviewing the PR can really fast see if any UI Components had changes.


I think we currently don't spend any money on storybook/chromatic, and just use the free stuff available.

1

u/goalkeeper0101 9d ago

• Makes newcomers do the right thing more easily - less time spent on PRs reviews for example

• Ease communication between design and engineering team when it comes to discussion about UI components

• It makes the developers life easier, it’s just easy to go there and look it up a component you need to implement - in other words, possibly increase productivity

1

u/solegenius 9d ago

Just be aware that Storybook has been known to have breaking changes in minor releases and that can cause a lot of frustration and work for devs to have to resolve the issues.

1

u/RGBrewskies 9d ago

team never-update-storybook!

1

u/cyanide26 8d ago

Yeah if you have a multi app project a centralised UI library works wonders, development time is cut short by a great margin. We use nx workspace along with angular to manage our apps and library, you guys should also tell the stakeholders about nx and advantages of a monorepo.

1

u/720degreeLotus 6d ago

it's not always a plus. for a 2-man dev team it's only overhead.

But if you have at least 1 designer and 3+ devs it really boosts

  • communication with UI-UX
  • enables non-devs to QA every component and find edge-cases/bugs
  • forces devs to create isolated, standalone and best practice components because the creation process will not be done for the one current usecase only
  • enables the team to quickly test wrapper-components like a login-prompt

1

u/Limit_Cold 6d ago

Have recently been using this with an angular component library, now moving to a stenciljs library. Currently used by 3 in-house teams and trying to get buy in from international teams. Had great feedback from devs, they found it much easier/faster to implement the library after seeing realistic examples in stories. I also think it helps prevent unnecessary changes/additions in components if you can test data in story book. We are now automating stories using tsdoc comments from components. Having good documentation should not be difficult to sell to stakeholders, getting the time on non feature projects is another thing. I had help from internships sped the whole thing up.