Agreed - and not advocating for edge cases to be ignored. But if the "happy path" somehow allows for a life to be put in danger, or comfort to be compromised, then something is wrong because those are basal requirements and really should have been surfaced early on as part of discovery. A table saw that cuts exquisitely but has no safety features suggests that the default scenario wasn't properly understood through a human-centered design approach.

A group of people can brainstorm extreme scenarios from the beginning, but is that really helpful? It distracts the team from focusing on the higher order problem and opportunity.

For example... if I had to make an app for people to share videos, I want to first focus on our target group, their goals, and create strong user scenarios - not chat about out what we're gonna do when the file size is too big or the server is down.

Those cases are important and need to be addressed, but I personally wouldn't dive in to them early on.

My 2 cents. Personally, I try to steer discussion away from edge cases until the happy path scenario is well understood and we have a really strong proposal for it. This is because:

1. There is momentum at the beginning of a design push. I want to capitalize on that and focus our creative energy towards finding a really solid "happy path" solution. This is the main use case for whatever you're designing, and if it's well-understood in the beginning, an edge case shouldn't necessarily blow it up.

2. I think that an early hunt for edge cases ends up giving them an outsized influence on the primary workflow. The workflow people will actually use 99% of the time. This can lead to early compromises that disproportionately affect the job to be done by the majority of users most of the time.

Then comes the time to invite discussion of edge cases and find accommodations, having a thick skin. I think detour workflows for edge cases are generally preferable to complicating the primary path... but of course it all depends. :-)

I'm in-house, so we have a core library that contains the elements of our company's design language system. For each individual project, we create an additional library which contains new components and anything we needed to customize from the core design system for that specific product.

We use Sketch libraries to keep our symbols in sync, which solves a big part of the problem.

For working on the same Sketch file, we have a manual system set up. For better or worse:

• There's a "master" Sketch file which only one person controls, the "gatekeeper".
• It contains all the workflows and states for a project.
• The master file is what we use as a source of truth and is what feeds Zeplin.
• Every designer on the team copies that master file, and appends their initials to the filename. These individual files become sandboxes for designers to work. They create new pages in the document as necessary.
• When changes are ready to be merged, they are sent to the gatekeeper. The gatekeeper pastes the new artboards in to the master, examines/tweaks them as needed, and notifies team that a new master is available.

Yeah, Figma would be a lot easier for this. Still, having designs funneled into a single “master” file helps us to ensure consistency because we have a human gatekeeper in place.

Would love to hear how others handle this.

Nice! This plugin makes Sketch work a bit like Fireworks. If it could somehow allow us to share/unshare layers to states and also not require manually refreshing states after updates it would be killer.