Excellent questions Sjors.
Yes I think that it was necessary to do the research and experience mapping as the starting point. Without it, we wouldn’t have discovered the most troubling time loss, nor would we have been able to evaluate strategies for solving it. Staff and faculty would still be looking up and cross-checking policy requirements against student records in multiple, legacy database interfaces.
My Director Chris Testa and I made strategic choices about which three forms to study. These three forms are the most complex in circulation here (aside from admissions). They contain all the elements that are used (in subset) by all other forms on campus.
An example to illustrate: combined numbers for the three complex forms we studied and mapped:
- 20+ eligibility criteria checked.
- 13 question-answer types.
- 10 types of reviewers.
- 2 types of conditional logic.
One of our simpler forms contains a subset of those:
- 6 eligibility criteria checked.
- 3 question-answer types.
- 2 types of reviewers.
- doesn’t contain conditional logic.
Since we knew about and built solutions for our most complex form elements, having them now in our back pocket makes the smaller forms (like this second example) easy to roll out. It can be viewed basically as a subset of the complex forms.
Had we studied, experience mapped, and deployed a simpler form first, we’d have built an API that required much rethinking, re-scoping, and retooling in order to scale up to more complex forms.
Your second point is incredibly insightful. It’s clear you’ve worked through similar challenges before. Yes, at any moment the project could be cancelled or resources adjusted. This did in fact happen to us. We mapped the experiences for three forms. All three saw “administrative adjustments” along the way. I think this happened in part because administrators saw we were building a new process and wanted to fix things about the old one that had been bothering them for years. On two forms, adnministrators also took “going digital” as an opportunity to change policy.
But we weren’t building our engine to be rigid, or have fixed policy. If an administrator changed a due date or changed who reviews the form next, well then it’s just a date to change in our engine, or it’s just the addition of a type of reviewer in a different slot. As long as the changes were within the three most complex forms (the ones we were designing around) then the changes weren’t headaches. Only minor adjustments.
In other words, we are building an API and interface that anticipates change. Not all change, but the most common policy changes that occur at UCLA’s Graduate School.
Related to all these questions, do check this out. It’s an article by Erika Hall about shifting away from doing research as a singular activity and toward an evidence-based design. She nails it.
Finally to answer your last question about if I’d do the same next time — no, I’d like to have launched more frequent, smaller experiments and prototypes and integrate more iterative launches and testing throughout. (Though to be sure, I’ve likely said the same about every project I’ve done in the last ten years!)