Tell Software Design as if It Was a Story
Users are the reason why software exists and sells. This simple truth must be the leitmotiv when designing software, yet it’s often forgotten.
Instead, sometimes, users are the protagonists, as it happens in the story below.
The product manager presents a new product the Company wants to build for writers who need support from generative AI.
“Nowadays, writers have a big problem. They have to compete with generative AI but cannot win. If they ignore AI at all, they lose. If they use AI, they are likely to plagiarize in some way the source that trained the AI.” — The product manager said.
“Moreover, no generative AI learns from experience but through the Internet. AI quickly produces perfect but Internet-based-average writings, and writers relying on it will collapse into that average.” — The same product manager added.
A raised hand.
“What constraints do we have to meet in selecting the technologies to integrate to build the product you describe?” — A software engineer asked.
“Two constraints: first, their cost must translate into a product price that is affordable for our target users; second, they must be replaceable with other equivalent and newer technologies.” — The product manager replied.
“The software architecture must be technology-independent to meet the second constraint.” — Another software engineer inferred.
“The software architecture must be designed to change, too. Our product combines the most ancient job, writing, and the most modern automation, generative AI. We have to link the past and future of writing.” — The product manager concluded.
On day 1 of the design phase.
“Imagine the product is already there. You need only to pull out your laptop and start writing. What do you expect?” — The software architect asked.
“Well, let’s imagine a specific writer, like a blogger. I’m a blogger, and getting a list of the ten most impactful problems my niche struggles with would be valuable.” — A software engineer answered.
“You mean that…” — Started the software architect, soon stopped by the colleague.
“I mean that writers make a living with their words, so our product should decrease their effort in selecting what to write about. Since I’m a blogger, I suggested something like the most impactful problems of my niche. I think we can generalize it like this: I’m a writer, I know my audience, and I want a service to tell me what’s relevant now for my audience.” — Clarified the software engineer.
“There’s no plagiarism on this, nor a technological dependency. On the other hand, it’s a natural task for a generative AI, and writers reasonably want to know what’s relevant for their audience in natural language. We get into the first feature of our product, which we can temporarily call ‘Prompter.’ What else?” — The software architect relaunched.
Many ideas came to the table. At the end of the session, three features came out that everyone deemed coherent with the product's vision.
“Let’s wrap up the session. I’m a writer in front of ‘Prompter,’ I get suggestions on what to write for my audience, I get a proofreader that double-checks the grammar and ton of voice, and I get a simulation of my audience to estimate how much interest they’ll have in reading my writing. That’s the MVP. See you all at the next session! We will start building ‘Prompter.’ — The software architect recapped.
On day 1 of the build phase.
“We’re all experienced enough to know that we’ll write ‘Prompter’ many times and that this is only the first. We don’t aim for technical perfection but an architecture open to change many times without collapsing into a whirlwind of technical debt.” — The software architect wanted to premise.
“I agree. In some years, writers may have different expectations from a service like ‘Prompter,’ so we assume that our core domain is the writers’ audience engagement. Instead, suggestions, proofreading, and audience simulation should be generic sub-domains.” — A software engineer suggested.
“We select from the market viable and ready solutions for suggestions, proofreading, and audience simulation; then, we integrate them into ‘Prompter.’” — Another software engineer proposed.
“That’s the approach I want. We must write as little code as possible for the MVP. What you propose goes in this direction. I plan to contact many companies in each generic sub-domain you highlighted.” — Concluded the software architect.
“Meanwhile, we build the integration and a great experience for writers.” — The software engineers stated.
A couple of months later, ‘Prompter’ is on the market.
“‘Prompter’ is having great success among bloggers. Instead, we’re almost ignored by novel writers and journalists.” — The marketing responsible reported.
“Yeah, when designing ‘Prompter,’ we kept bloggers in mind. We knew the risk of targeting less than all kinds of writers. On the other hand, if we didn’t refer to specific writers, how could we have designed such a great experience?” — The software architect said.
“The blogger’s market is insufficient for the ‘Prompter’ financial goals. You must address new writers’ kinds.” — The marketing responsible stated.
“We designed ‘Prompter’ to change. Give me a couple of months.” — The software architect said.
The story above shows that software, in 2023, is marginally about coding. The user’s experience is the steering idea.
On the other hand, writing code is costly to build and maintain. The less, the better. The focus shifted from code to users.
This shift changed the design language, much closer to storytelling than UML.
Think of GPTs: they are still ingenuous applications but go beyond the surface! Instead of giving suggestions on how to look after your dog, they could soon become micro-services interacting with each other to make an enterprise application work.
How do you build GPTs? By telling the story of the behavior you want.
But there’s a huge ‘but’!
GPTs will be incredible facilitators in building software, but the method for conceiving and crafting the storytelling to feed the AI has already been there for years: Domain-Driven Design. Don’t confuse the tool (GPTs) with the idea (building software around users).
And we are back to the storytelling. In the past, it was a way to sell, and now it has transformed into a way to build software.
Are we coming back to the origin of human thinking? The storytelling, from myth to selling approach, and, eventually, the definitive interface with AI.