When dem dey make software, dem dey always try to make sure say wetin dem plan (specifications) and wetin dem do (implementation) align.
Because of this, we dey design software so e go fit the plan, then we go build am based on that design. After that, we dey use tests to check if wetin we build really follow the plan. If e no match, we go correct am, or if the plan no clear, we go make am clear.
We fit call this kind of work "specifications-and-implementation-based engineering."
But now, when people dey talk about software, dem dey give user experience more serious attention.
Again, na the way the software dey behave, no be wetin dem use build am, na im dey truly shape how the user go feel am.
So, apart from the plan and wetin dem build, experience and behavior still dey.
Because of this, I believe say e good to look into "Experience & Behavior Engineering," wey be say e dey based on experience and behavior.
Liquidware
Experience & Behavior Engineering no go fit work well with the old ways dem take dey make software.
This na because e go need us to make user experience better without strict boundaries or clear-cut functions for the specifications. Even small request from one user to make e experience better fit mean say we go throw away all the software wey we don build before.
But then, if time come wey dem go dey use AI wey dey generate things to make software automatically, then to rebuild software from scratch go dey okay.
Again, for that kind time, if dem put one AI engineer chatbot inside software wey don release, e fit be say we go enter "liquidware" age. For this age, you fit change the UI to fit wetin each user like.
Liquidware mean say e go soft pass the normal software wey we know, e go fit individual user kpatakpata.
When this time of automated development and liquidware come, the old way of making software based on specifications and implementation go old.
Instead, we go move to Experience & Behavior Engineering.
Wetin Be Behavior?
To just put am, behavior na one state wey dey change as time dey go.
And to test behavior, na to test this state wey dey change with time.
Again, testing behavior no be to confirm if e match one specification wey talk how states dey move from one to another. Instead, dem dey test behavior based on how good the user experience be.
Of course, if bugs dey wey dey make the system do wetin the user or developer no intend, dem too dey spoil the user experience well well. So, behavior testing include checking if e dey follow function and if the function dey valid.
After dem don meet these basic functional requirements, dem go con focus on testing for high-quality behavior from the angle of user experience.
The Best Experience
For us human beings, the best user experience na when you fit control your body well well when you dey healthy.
Just think am: everyday, we dey control our body wey complex, get plenty limitations and restrictions, and weigh plenty kilograms, we dey use am do wetin we want.
If person wan try to control one system wey dey heavy, complex, and get plenty limitations like that to do wetin e want, the experience go normally bad well well.
But, as long as we no dey sick, we dey move this our heavy, complex, and limited body like say e no get weight, we dey control am easy like say na simple machine, and we no dey even think about e limitations or restrictions like say dem no even dey there.
This na the best experience.
If we follow good behavior, e fit be say we go fit give an experience wey dey close to controlling your own body.
Meaning say, even if one system dey slow, get complex functions, and get plenty limitations and restrictions, you go fit get a liquidware experience wey no go give you stress at all.
For Conclusion
The best liquidware go give us experience wey go be like our own body.
That kind liquidware go turn to something like body for us.
Every time the best liquidware plenty or dem add more power to am, e go just be like say our own body dey expand.