What Is "Progressive Disclosure" and How Does It Impact Developer Portals?
Have you considered using "progressive disclosure" within your internal developer platform and portal to help manage cognitive load?
Join the DZone community and get the full member experience.
Join For FreeProgressive 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 in July 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 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 read the beginning of 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."
"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."
Providing the underlying platform API and lifecycle management support (controlled) access to a wider range of configuration options, you can expose these to developers working on day two issues, perhaps via the "advanced" configuration options within your portal.
Final Thoughts
In my experience, it's all too easy to overfocus on the day-one story when building an internal developer platform and portal. While you obviously need to quickly provide value to developers, you have to think more strategically to ensure longer-term adoption.
What do you think? Have you considered the impact of progressive disclosure when building your internal developer platform?
Opinions expressed by DZone contributors are their own.
Comments