I'm unapologetically leaning into the work notes this week because it's been manic and there's no way around it.
Too much, too late
OK, so the background to this is that there's a bunch of climate-related content that needs delivering to the industry website by a hard deadline (which happens to be Monday of next week).
There's a UX challenge in presenting a large amound of dense information, and this has fuelled demand for new UI elements, which need corresponding CMS components.
And basically it's just been too much work to do well in a week. Our sprints are two weeks, but about half that time is used up in ceremonies.
One of the pieces of work has been fine; cards in a grid layout with some programmatic theme variations depending on context. I did that yesterday.
The other piece has been significantly more challenging: an inline form with real-time field validation that enables a button that simultaneously submits data and downloads a document. I mean, don't get me wrong, it's not outlandishly complex stuff, but there are at least 3 or 4 things in there that we don't have pre-existing solutions for and which need to be engineered from scratch.
That's about the size of it. I'm pretty satisfied with this synopsis, which captures the situation in a few words and doesn't dwell on all the technical minutiae and details of my emotional journey. We'll get down to brass tacks in the retro.
The main conclusion I've drawn is that this situation has pitched UX design and dev work into conflict and that's unfortunate. In retrospect, I feel that we should have proceeded more like this:
1. Build a working solution
We should have started with what we had and made something releasable as a fallback: a piece of content describing the download and linking to a form.
IMO we ought to have set up an automated email send that delivered the document to the address submitted.
2. Submission activated download button
On form submission a disabled download button would be enabled, allowing the document to be downloaded immediately. This could also work without JS, which no-one seems to care about but me.
Huh. I just realised, we could maybe even automate that process by including a script that fires when the server success message is received 🤔
3. Submit and download
Having established a baseline mechanism for submitting-and-downloading, we could seek to improve upon that with scripting to smooth the process.
This is potentially a full sprint's worth of work to do properly, but IMO we'd potentially end up with a much better solution. A pair of Submit and Download CTAs that would progressively enhance into a single action in the presence of JS; modular and fit for inclusion in a variety of contexts; tested against all the required devices and OSs.
4. Move it all inline
At this stage the various aspects of the solution ought to be discrete and well-understood and capable of being composed together into a content block to sit on any page you like.
Admission
Of course, it's easy with 20/20 hindsight to say that this is what we should have done and present a narrative that's problem free. Who knows what technical blockers we might have experienced en route to that perfect solution?
The other very likely outcome is that having launched a working solution and moved on to other pressing work we would never get around to iterating on the solution, and be left with a clunky user experience. But maybe that's all we can afford?
I'm thinking of keeping a list of prompts in the style of Oblique Strategies based on these kinds of thoughts. This one would be:
What kind of debt can we best afford?
…or something along those lines. How much debt can we afford to incur? What lines of conflict are being drawn?
Good stuff
- worked hard, made lots of progress
- collaboration with BE engineer
- understanding of the CMS and freemarker improved
- fixed a separate content issue (storystream)
- added documentation to the knowledge base
- actually did some javascript for a change
- lots of grist for the mill in terms of dev practices
- no guilt or shame!