The art of ta da.
“Ta Da!, Whadda ya’ think? Well…”
The big reveal is finally here! After weeks cooped up in my creative silo, I’m ready to unveil the fruits of my labour. What do I expect from my stakeholder? Nothing but jaw-dropping joy, praise and adulation of course. I expect confirmation this piece of work is going to blow the minds of all who experience it. I’ve used loads of new stuff, nudged pixels a single digit, spent hours getting that ‘ease’ nailed in an animation. And the result? Digital perfection. How can anyone find fault in this?
I may be brimming with confidence but inside there’s some serious uncertainty. Will they love it? How do I know for sure? The answer… I don’t.
Where did this uncertainty come from? Let’s turn back the clock
Rewind two months. As the chosen digital learning specialist for this project I’ve just met with my stakeholder to discuss requirements for their content. I suggest some different ideas, we agree a timeline for delivery and arrange a couple of catch up meetings.
Right then, let’s do this. With requirements captured, I set off to ’better my last’. I’m going for flippin’ perfection, I’ve got ages. Should I refer back to past ideas to see if any styles could work? HELL NO! Straight on the web for some bleeding edge design and development…. OMG! That looks awesome. Those icons totally pop and that UI is perfect. I’m ready to show off and get the applause I deserve.
Back to the Big Reveal
”This is amazing!” the stakeholder exclaims. (Bloody hell, I’ve nailed it). “But … what does it do…?” they add quickly. “I thought you said the entire programme would work seamlessly across all manner of devices… ?” Uh oh.
“Check out what this does!” I challenge, attempting to rescue the Big Reveal. Pointing out the intricate nature and pixel perfection of my bells and whistles design. The stakeholder just looks confused.
Two months’ work. It’s a long time polishing something that doesn’t quite meet the needs of my stakeholder. And if it’s not right for them, then what will the people who are actually going to be consuming this content — the end users — think?
I’ve been barking up the completely wrong tree here! This is a back-to-the-drawing board job. And it has to be a quick one as it’s launching within the next week. What’s most frustrating is, it didn’t have to be this way. Here’s how.
The art of ‘ta da’.
Express check in
Let’s start with the Big Reveal. Or, should I say, avoid it.
A majority of my nervy uncertainty (a bit keeps you grounded, right?) could have been avoided if I’d checked in regularly with my stakeholder. Our Agile approach to delivering projects means this is no longer a problem. Working as part of a sprint team, our daily 15 minute stand ups and frequent contact with the product owner (the person on the hook for getting the right solution for the end user) ensure we are on the right track. Transparency across the work means there are no surprises or scary “But what does that do…?” questions.
What about our perfectly designed digital solution? Did we ever think to run this past users? Nope! Whilst we shared it with focus groups when suitably polished, it would’ve been far more beneficial to include them throughout. If we had, we would’ve gathered valuable feedback and data on the solution as it was built. Couple this with the regular check-ins mentioned above and you can be much more comfortable that you’re delivering the right content in the right way for the real end-user.
We have all the time in the…. next two weeks
And the timescale for delivery? With my deadline set way off in the distance, I had this big window of time to tweak, tamper and dabble to perfection. That’s great right? Nope. A lot of wasted time actually. No need for over-the-top solutions that get in the way of something actually useful. Forget bells and whistles. It’s got to be addressing a clear point of need. It’s got to be what the end user wants and the business needs. Through research and continuous end user involvement you can create a solution within a much shorter timeframe. Which is what we’re doing now as a result of Agile. Prior to the ‘build’ sprint we carry out a research sprint or discovery phase that allows us to gather as much information as possible and identify clear priorities (features) for the solution. These features are then ranked by importance to ensure the sprint team are always focusing on the most valuable elements. This also means, come the end of the sprint, our solution is more likely to meet the needs of the end user. The research sprint provides the opportunity to identify a group of key people who we can test the solution on. The feedback they provide helps measure the effectiveness of the ‘build’ sprint and means we can iterate the solution, enhancing it to make it even better. Only at this point, can we include a well considered bell or whistle to enhance the experience.
Focus on the Minimum ‘Valuable’ Product (MVP)
Let’s be clear. Minimum doesn’t mean unfinished or basic. Its also worth mentioning that, in the truest sense of the term, the ‘V’ in MVP stands for viable not valuable. I think however that they both work. Yes, the solution has to be viable (ie. workable, usable, operable for the end user). It also needs to be valuable (ie. make a difference and benefit those that interact with it). Our fortnightly time-boxed sprints ensure we focus on delivering data-driven solutions that are valuable to our end user. Getting that solution in front of real users quickly, means we can start collecting feedback in real time and then iterate and enhance that solution with confidence. Here’s an example:
We recently worked on some development for our graduates. At the outset we used feedback from previous graduate development sessions to form a high level plan of what we would focus on this time round. We then ran it past our end users (the graduates!), to ensure we were developing content that would meet their needs. We held numerous user interviews throughout the research phase to glean as much valuable information as possible from them to make sure we were on point. No ‘build’ work took place until we were happy we’d collated the necessary quality and quantity of user research. Aware of our tight deadline, we swarmed on this research phase to complete it within 2.5 days. Once the design and build commenced we worked our way through the prioritised task list. Content went through an internal review (sprint team) and external verification (product owner/user) process before it was considered ready for release or ‘done’. The final solution was a series of digital resources which addressed a clear point of need for the graduates, as well as a single day, highly interactive business challenge. The challenge gave them the opportunity to test the skills and knowledge gained from the resources.
In our old world, this would have taken up to two months to develop and be delivered over ‘x’ number of days in the classroom, alongside a variety of media that had been created for what we (not the user) considered relevant to the end user.
In the new Agile world of our L&D team, delivery of a solution is within two and half weeks. So quick! And with confidence that our solution is actually what the users wanted and needed. There is also the added comfort that it can only get better. How? More data/feedback gathering from users who have experienced the solution. This helps us learn, enhance and release for the next time.
SOOO, not a showcase
At the end of our sprints we present our work back to the product owner in a ‘showcase’. Quite a contradictory term really, given we’ve maintained regular contact throughout to check we are on the right track. ‘Showcase’ conjures the notion of that Big Reveal. A rabbit, a hat and gasps from a mesmerised audience.
In Agile, a showcase is the opposite. It’s about no surprises. What do I expect from my stakeholder during this ‘so not a showcase’ then? It’s clear acknowledgement of what has been achieved by the team, and recognition of a valued solution delivered. No fanfare or bunting. What about bells and whistles?! — only if the end user wants them.
Are they going to love it? Probably. How do I know for sure? By making sure the team and I use an Agile approach to delivering the right MVP.
