Have you considered using "progressive disclosure" within your internal developer platform (IDP) to help manage cognitive load? 🤔
What is progressive disclosure?
Progressive disclosure is a UX design pattern that reduces cognitive load by gradually revealing more complex information or features as the user progresses through the UI of a digital product (such as a portal).
Why should platform engineers care?
I've encountered the term a few times, but its value really hit home last week during two panels I participated in. First, in the LeadDev panel "How to implement platform engineering at scale," Smruti Patel mentioned this. Then, in a Syntasso panel that I hosted with Abby Bangser, "When Terraform Met Backstage," our guest, Seve Kim, also mentioned progressive disclosure.
This concept impacts software delivery on days one and two (and two thousand).
Day one challenges with internal developer portals
I've recently heard stories of developers being overwhelmed with portal scaffolding configuration options when trying to bootstrap a service (and the same problem applies to that mandatory 100-line values.yml Helm file!). A better UI experience might provide hidden "advanced" configuration and/or a series of steps to help navigate the user through the choices.
I originally posted this article on LinkedIn, and Chris Plank, Enterprise Architect at NatWest, shared several great observations in the comments:
"Completely agree with this principle we’re actively using (as you know) with Kratix of opinionated promises and limiting the options for the consumers of the product to have to know about and fill in. Over time, we can add more options and more functionality and even have opinionated products vs un-opinionated API’s using the same underlying promises."
He continued with what I considered to be a "mic drop" moment, stating that the opinions offered within a platform are what makes it an effective product (or not):
"The more options we give people via UI’s like backstage, the less benefit it becomes. “The option is the glue, the opinion IS what makes the components a Product” had become a bit of a mantra of mine lately. Without that product opinion it’s just an API and higher cognitive load etc….all the things we really want to address by using opinionated platform as a product in the first place."
Implementing progressive disclosure within your platform can ultimately be useful to your customers (developers) from day one onwards.
Day two thousand challenges with platforms
At the opposite end of the spectrum, I've also heard stories of developers struggling with debugging and fixing already deployed services and delivering value to users. The portal doesn't allow them to make the required configuration changes, so they have to "break glass" and do a manual hack (or escalate this to the SRE/platform team).
In the LinkedIn post comments, Chris Westerhold, Partner - Consulting and Partnerships @ DX, made several great points about the need for strong product ownership to support the day two challenges with platforms:
"Progressive disclosure is such a fantastic way of building great experiences. This is especially true when you have great personas/jobs-to-be-done for the folks using your platform. This takes really good product management and feedback mechanisms to understand your users. I am glad to see folks talking about this stuff, as it gets glossed over far too often."
Implementing progressive disclosure with Kratix and Backstage
We're thinking about this a lot in the design of Kratix, our framework for building composable IDPs. Encoding sensible service configuration defaults into a Promise (an API for X-as-a-service) and choosing what options to expose to developers is a good start for days one and two. As our already popular Backstage integration evolves, we'll listen closely for customer feedback that hints at the need for hidden "advanced" config options and "break glass" support within the portal itself.
Questions? Please reach out!
What do you think? Have you considered the impact of progressive disclosure when building your internal developer platform?
If you have any questions or want to explore how we can help you build an effective internal developer platform, please contact us! (And don't forget to sign up for our platform engineering newsletter)
Comments