The world of EdTech is littered with less than prestigious applications and tools.
The majority have some success, a small band of avid users but never get any significant traction.
Rather depressingly, a tiny minority become quite successful even though, in my humble opinion, they are not very good.
A similar small number are actually very good and very useful and fully deserve the success they achieve.
Ultimately, the L&D market will control the fate of PerformaGo; but one thing I knew from the very start.
To have a hope in hell of landing in the latter of those three categories just described, PerformaGo needed to have a clear and valuable conceptual framework underpinning it.
At the start of the journey, I thought I had the basis for that framework in the shape of Gottfriedson and Moscher’s 5 Moments of Need – possibly the best-known piece of thinking there is about supporting workplace performance.
This time last year, it appeared to be a logical starting point. It made perfect sense. It connected well with all of the other frameworks and processes I teach (and use) as part of my wider impact and instructional design thinking.
However, once I finally started applying it for use with PerformaGo, it didn’t quite hold together. I realised I needed something different.
And I want to be clear. I’m certainly not suggesting that the 5 Moments framework is somehow flawed. Definitely not the case.
It provided a solid base from which I was able to diverge onto a slightly different trajectory.
Something I could definitely not have done without that foundational thinking.
Needless to say, refining this didn’t happen overnight. It took several weeks to get to the first iteration of what I’m currently calling The Performance Flow Framework.
There have been multiple iterations in the weeks and months since. And it’s still a work in progress, with some smaller tweaks and iterations still happening right now.
Broadly speaking there are three component parts.
First, there’s the overall three-phase flow of performance, which provides the high-level structure. This, I think is stable and unlikely to change.
Within each phase there are several support purposes which capture (at a high-level) what we might be aiming to help the performer achieve, within a given performance instance.
These are based on the 5 Moments concept but refine that thinking to a more nuanced level of granularity.
Again, I believe the purposes are stable and won’t change; however, the naming of a couple of the purposes is still in flux.
And then, finally, each support purpose, consists of a handful of support elements.
These are the practical ways in which support will be provided/presented to a user of PerformaGo. It’s at this level of the framework that most work is still happening.
At a conceptual/cognitive level, the elements are stable. In other words, what they are and what cognitive function, broadly, they support won’t change
But the how each element is constructed is still a work in progress. This is about what content goes into an element; and how that content is best constructed and presented.
Some elements are relatively straightforward and have been very easy to define and complete.
The thinking around all this has become particularly acute now I have started work on a prototype.
This is forcing me to think in real detail about what needs to happen in the edit modal for each element and how any modal input converts into user-facing output.
And it’s this aspect of the design work that I’d like to explore more in the next of the ‘Big Shift’ posts.
Until then…
