I found an interesting use case for Quint: designing UIs. I'm building a voice-first app. Instead of describing the UI to pen.dev, I gave it my Quint specifications and asked it to draw every state of the voice capture flow. It came back with 28 screens representing different states across 6 stages, and several of them I would never have thought about or drawn myself. Two takeaways: 1. Some failure modes are worth keeping as separate screens. My spec treats "you left the app" and "a phone call took over the microphone" as different interruptions. Telling the user what happened makes the experience better. 2. Some failure modes are worth folding. My spec has six different ways the mic can fail, and each one needs to be tested. But the user can't tell them apart or fix most of them, so on screen they become one card: "Couldn't turn the mic on. Try again, or type it for now." UI mockups usually show the happy path you're expecting plus a few failure modes. Executable specs like Quint show the paths your system can actually take. Now, I model the critical paths of my system in Quint, and use those specs to draw the UI. Give quint by @informalinc (quint.sh) a try. It's a game changer.