Well, this is new!
One of my favourite sessions of Claris Engage (FileMaker Devcon) has been the demonstration of coming features - that Rick would always preface with - may or may not make it's way to a coming version of FileMaker.
With the release of Claris FileMaker 19.1.2, we Mac OS X users received a 'preview' of a new feature for working with layouts and more particularly layout objects.
This is new for more than one reason - this is the first time a preview of a coming feature has been included in a release update. Let's disregard the actual layout features themselves, this is the beginning of Claris' change of delivery method, to provide a 'prototype' of a coming feature, to be more 'agile'.
This is prototyping at it's most agile. Consider for a moment how you - as the Developer - would respond to a client brief for a new function to create layout objects.
I'm going to assume you'd retire back to your work office, and start writing up pages and pages of proposal documentation, mainly focusing on describing the features, with your best word-smithing - pretty sure that's not a real term - to then return to present to the client, assuming the words will be received and interpreted as intended - to then receive the permission to head back and start coding and developing the solution.
Too often, the next presentation of the first beta of the solution is met by frowns and concerns from the client that this is not how they though the solution would be.
Words alone can not explain or define how software will 'work' - how the User Experience (UX) touches the user. Sure, wireframes and flowcharts can attempt to define, how your software solution will actually work - it's just we are leaving ourselves open to interpretation.
Now before you shout your objections to spending hours crafting a final and polished result without getting client approval on the solution or the budget, this is not what we mean my 'prototyping'.
At best, a prototype is the minimum viable product (MVP) to begin 'directing' the conversations round the next build, allowing the 'end goal' to present itself during the iterations to naturally present itself . . .
Most projects are adjusted and redefined, during the delivery process, and most vaguely resemble the written proposal we all agreed on, in principal, back at the start.
As a 'prototype' of this agile workflow, I'm suggesting that the next project you start - where you would generally provide a written document as the first response - ask for an agreement from the client for you to create a MVP this time around, based on a similar time frame to create a written document.
I believe you'll find this a win for the client, a win for you, and most importantly - a win for the end user . . .
Comments