A colleague and I were tasked with creating an interface for a non-technical user to hook up the connections that could come from Forge, to Forge or a combination of both.
To simplify a fairly technical feature in a way that a persona with limited technical understanding could plug information that they obtained from a network admin into the correct fields in order to connect a 3rd party software.
Our research began with knowledge transfer from our internal network admin. He gave us a very technical overview of how APIs work within the Forge ecosystem. There were numerous terms that we needed to familiarize ourselves with such as "source/sink", "webhook", "connectors".
After a couple sessions of what I felt was a very technical, right-brained explanation of the process I keyed in on the loop of data in the illustration below. I realized for our scenario that most everything outside that loop didn't pertain. So I asked the admin, "so tldr; this is just data coming from Forge and data coming to Forge and the keys for that data to move in this loop?" "Yes." "Got it."
Once I had the much simplified version of the process in mind, I was able to go off and sketch an interface that presented this less daunting approach to APIs to our users. I keyed in on the to/from concept and utilized graphics to help underscore that concept.
I've always felt that one of my design superpowers is to cut through the clutter of an issue and see the core concept hiding behind that clutter – core principles thinking.
Once you can see through all of the new lexicon being thrown at you, the preconceived notions of the SME/user you're interviewing and the technical constraints of the existing way things are done, you probably have a really good start on how to solve the problem.