When I worked at Sikorsky Aircraft helping design the CH-53K (pic attached), I heard the word "Requirements" 100x a day:
Requirement-123: The helicopter has to be this wide or the HMMVW won't fit.
Requirement-456: The avionics has to send this signal to the flight control computer.
"What do the requirements say? That's not in the requirements."
Etc
And when you're doing a clean sheet military product, this is critical.
We are parceling out precise functionality to 50 different suppliers and everyone has to hit their requirements for it to all work.
But when I'm working on WalkMe for clients, I never say the word requirement.
It's just not in my vocabulary anymore.
Here's why, quick story:
I recently spoke with someone who was trying to build out an ActionBot to solve a simple form filling use case.
They had an eye-glazing monster spreadsheet with every single field that existed across multiple pages of this particular process.
What field type it was.
What data it contained.
Whether it was needed in process A or process B or both.
Notes, questions, highlighting, comments.
"Requirements", am I right?
Yeah, no. Don't do this.
Customer was upset because the development bogged down looking at this spreadsheet.
When one person does "discovery" but then you "outsource" the WalkMe development to another party, there's a tendency to do this.
"We need to debate and document the requirements in this spreadsheet so thoroughly that the junior WalkMe builder I'm handing this off to couldn't possibly have any questions."
But we're not building a helicopter here.
We're a configurable UX overlay on top of a configurable system in order to improve an underlying business process.
The only real "requirement" is we put the best solution out there that balances all the design trade-offs and improves out client's situation as much as possible as quickly as possible.
And many times, the WAY a feature works in the UX will force a certain design solution or direction.
"Oh, I didn't know it would look like that, let's do it this way".
Then your "requirements" are out the window.
To avoid getting stuck in the spreadsheet, I recommend building out the UX as quickly as possible.
We want to pick the simplest use case and build it out end-to-end.
Go all the way from user initiation through prompt and response, auto-fill, submit. And understand the back-end analytics.
You don't want to "Waterfall" this by phases.
You want to get through an entire pass once. Learn, adjust, tackle more complexity next.
Now, you're going to have a hard time doing this if you're trying to have one person be an "Analyst / Project Lead" who does "discovery" with the client and someone else be the "builder" who we hand it off to. That's another reason I don't outsource building but that's another topic.
How much do you focus on "requirements" when building DAP content?