Discoverable by Design: The Hidden Superpower of Great Software — On Discovery Patterns. Ironstone NFRs 1.0
DesignedandSynthesized™️ by @RobTyrie, Founder of Ironstone stone Advisory 🧲🥌
This is the first part of a series of essays and thought pieces about non-functional requirements. this is all the stuff that has to be in every application if not at the beginning it shows up in the end. things like login screens and search bars and share the social media buttons are non-functional requirements because they’re not the center piece of the function point that you’re implementing like a specialty stock exchange index like a VIX tracker or Accounting system.
We’re going to start talking about Discovery as a key pattern. I have a hypothesis that all nfrs are really protocols and should be defined as such instead of hard code or even no code generation. this is where the lovely patterns of computer science and systems design engineering meet. rt
1. The Pattern: Why "Discoverable" is the Design Trait You’re Not Talking About—But Should Be
Imagine buying a state-of-the-art espresso machine with a secret button that unlocks cappuccino mode—but no one tells you it exists. That’s how most apps handle their features today.
"Discoverable" is the espresso button. And it’s buried under layers of cognitive load, lazy UX, and lack of empathy for the end user.
Discoverability isn't just a nice-to-have. It’s a non-functional requirement (NFR)—a pattern of design thinking that determines whether your software becomes legendary... or forgotten.
---
2. What Do We Mean by Discoverable?
"Discoverable" means a system should:
Be easy to find (from Google to GitHub to app store to intranet)
Be easy to start using without external help
Have features that reveal themselves naturally (like doors that push when they say “push”)
Support progressive disclosure (teach me a little now, more later)
This is UX-meets-systems-design-meets-behavioral-economics. It’s a design pattern with serious ROI.
---
3. Real-World Examples of Discoverability Done Right
Slack: Slash commands offer power users shortcuts, but the interface hints at them without being overwhelming.
Figma: Layer and component interactions are intuitive, and tooltips teach you as you go.
Notion: Blocks offer discoverable functionality with an on-hover plus sign—clean, efficient, progressive.
Gmail: Smart features (like snooze or labels) are hinted at subtly through UI nudges and onboarding.
---
4. Why Discoverability Matters (and Why You’re Losing Money Without It)
Psychological & Behavioral Economics Effects:
Cialdini’s “Commitment & Consistency”: Once a user starts using a feature, they’re more likely to keep using it.
Thaler’s “Nudges”: Subtle design cues improve feature adoption without force.
Kahneman’s “System 1 Thinking”: If discovery requires too much thought, you’ve already lost.
Business Impact: Increased feature adoption = better ROI on your dev team’s time:: Lower support costs = fewer tickets asking “where’s the damn button?” :: More loyal users = emotional attachment to tools they understand
---
5. The Pattern Language of NFRs
We need a pattern language for non-functional requirements, just like we have for architecture (thank you, Christopher Alexander).
Non-functional requirements are like gravity in system design:
You can’t see them.
You can’t ignore them.
If you misunderstand them, your system collapses.
Here are just a few "invisible" NFRs that should be part of every user-facing or user-touching system:
1. Discoverability (our focus today)
2. Learnability
3. Usability
4. Accessibility
5. Performance responsiveness
6. Resilience & error recovery
7. Security (UX-level prompts & flows)
8. Service continuity awareness
9. Observability & transparency
10. Search & navigation patterns
These aren’t constraints. They’re design accelerators. We will cover all 10 patterns in this series of separate parts.
---
6. Implementing Discoverability in 7 Steps
1. Start with a search bar. Yes, even if your app is small.
2. Introduce feature tooltips gradually, using progressive disclosure principles.
3. Use onboarding for discovery, not just setup.
4. Track feature usage analytics. What’s being missed? Nudge accordingly.
5. Run “5-second” usability tests. Ask new users: “What can you do here?”
6. Link to short-form help and tutorials from within the interface (modals, bottom sheets).
7. Design like a good waiter: helpful, unobtrusive, always available.
---
7. The Discoverability Checklist
(Use this every time you ship a feature)
[ ] Is the feature visible on first glance?
[ ] If not, is there a clear cue leading to it?
[ ] Does the user get feedback when they engage it?
[ ] Can a new user guess what it does?
[ ] Does it fit into the user’s mental model?
[ ] Is there a way to recover if they make a mistake?
[ ] Can they find it again later easily?
[] is there a QR code button?
[]is there a help button?
[] is there a share everywhere button... (this is to help other people discover your genius)
[] did you establish bread crumbs for workflow apps?
[] did you record transaction and accessible human rear business event log that is automatically searched and has and?
[] are there hyperlinks and application to go to the next logical place?
[] did you enhance vertical scrolling or horizontal scrolling that is natural and well discovered logical summary to detail pass for human readbility and Discovery especially on narrow windows and mobile devices? scrolling is a human superpower.
---
8. Where Discoverability Fails: A Satirical Shortlist
These are also known as softare anti- patterns.
The "hamburger menu" graveyard: All your key features buried three taps deep.
The AI assistant that solves world hunger but has no “On” button.
Error messages that just say: “Oops.”
For long running operations, no progress bars.
no cues for work that you’ve done.
no embedded status reports for what you worked on in the last 4 hours because you know you can do that afterwards by hand.
Search bars that don’t search full text and image.
Onboarding that teaches how to use features that no longer exist.
Trying to squeeze things into one screen and dropping discoverability features.
No context based user-help
User documentation is feature-based and not case based for the vertical
hoping that virality will occur solely based on your genius and no thinking empathetically about your users I do not have your genius.
when I think about why people don’t do this.. by people I mean developers and architects.. I usually come to the conclusion that they’ve never operated business and they never really thought empathetically about all the things that a person using their software and instead of software that they’re doing has to do for a living. previously stick to a spec designed by a person who also doesn’t know what it will user does for a living. I think it’s transformed into something that people just don’t use. Design Discovery into your apps and put it on your backlog that’s my advice. If you do the design patterns right someone will send you an AI agent or low cost approach to doing this kind of work. this is how spunk and data dog emerged for instance. it’s also how databases emerged as a standard protocol in building useful applications faster
This stuff really does take systems design and component engineering with layered interfaces and loosely coupled objects.
Discoverability sins cost users time and companies millions.
---
9. Discoverability Beyond the Interface: Backend Services Too
Even backend services need discoverability—just for a different audience:
- Clear API documentation
- Working code examples
- Developer portals with try-it-now sandboxes
- Feedback loops for documentation updates
- Get your GitHub hygiene on
- Archiving control and actions should be automatic
- Discovery takes analytics, and #observability. Instrument your systems.
Even M2M systems should be designed with observability and traceability in mind. Discoverability here supports debuggability.
If you're designing for devs: make the invisible visible.
---
10. From NFRs to Narrative: Why This Stuff Feeds the Soul of Software
Discoverable systems feel... alive. They respect the user. They whisper “I got you” instead of yelling “RTFM.”
When you build with discoverability in mind, you build for:
Humans, not just users
Curiosity, not just consumption
Exploration, not just execution
It’s systems thinking with empathy wired in.
okay here’s a very important point.. just like there is test driven programming… there is a possibility to do Discovery as something similar where it’s an aspect of code that is generated… based on the PRD of your software component. my advice is to designing discovery and build in automated agents that do it for you this is simple coding relatively speaking because it repeats as common patterns if you haven’t already noticed that imagine is a superpower of AI and so is transformation. it’s a lot easier if your domain is very narrow and by its nature a software application is a narrow domain if you’re just trying to do discovery about it
Think about it. Discovery is really just a transformation view based on your application which is the “domain” of Discovery in this case. you can generate these with advanced AI coding tools like Claude.ai or Gemini from Google. whatever the top AI coding IDE platform is for your stack.
---
11. Next Steps and Endnotes
Practical Things to Do This Week:
1. Audit your current feature set. What’s underused? 🤔
2. Interview 3 users about what they didn’t know your app could do. 🎤
3. Add tracking to one overlooked feature. 📈
4. Design one new tooltip or inline help cue. 💁♂️
5. Host a “Discoverability Sprint” inside your product team. 🏃♂️🏃♂️
Bonus Reading:
- The Design of Everyday Things – Don Norman
- Nudge – Thaler & Sunstein
- Thinking, Fast and Slow – Daniel Kahneman
- Persuasion – Robert Cialdini
- Pattern Language – Christopher Alexander
these are required reading if your billing software in 2025 or later. they’re all based on intense understanding of neuroscience and behavioral psychology
Hashtags for Visibility:
#Discoverability #UXDesign #NonFunctionalRequirements #ProductDesign #SystemsThinking #PatternLanguage #DesignPatterns #UserExperience #DevTools #IronstoneAdvisory
This post was designed to be a prompt. logical use of it would be in perplexity to expand any of the items are interested in and then add your last PRD and do a discovery audit on yourself immediately with artificial intelligence.
---
All metaphors were user-tested on real humans. No systems were harmed in the making of this post.
the founder of Ironstone Advisory, is a veteran software industry guy. He has aspirations of driving around in his Wrangler or an RV doing Discovery Audits face to face with developers on applications and then using that experience to develop swarms of Discovery AI Agents to help people out everywhere to make better software for regular human beings. 🧲🥌 (these are the Emojis I automatically get when I search “iron” then “stone”... they change on different platforms)
