Designing for the Platform — Extension Points

Last time we covered the Service API providing a design for the core API’s that make up our system, the fictitious To Do or Task system.

Now let’s focus on the Application Extensions. To do this we need to make use of our User Experience Model because here the developer will be able to create an extension of the User Experience we provide. What does this mean in practice?

Well, let’s imagine as part of our User Experience Model we had a drop down menu to let a user select from a set of actions, like attach a file to a Task. One place we may allow for an extension would be to let a developer add a new menu item and provide their own Service API to handle the action. Something like this;

And the menu

Now let’s say a developer wants to integrate a service like Box — he wants to extend this menu to let that user select from Box.

Of course that would not be the end of handling this — since that Developer needs to let that user select which file AND the developer needs to know the identity of that user so they the right list of files are shown to that user to attach.

That means there are at least two more things we have to do here to support this developer. First we have to provide an extension point in our User Experience for them to plug in their Authorization UX — to make sure they connect the user to their system and maintain security around their system and it’s artifacts. Also we have to give an extension point so the developer can show some experience to let the user pick from a list of files and then complete the round trip back to our UX…which likely means one more thing, we have to give them a way to show that attachment and also (at the Service API layer, give them and API to make sure they can attach a file to this task object).

If we think about this in more abstract terms, we need;

A way to extend menus

A way to allow for a developer to inject an Authorization UX into our UX

A way to allow for a developer to inject a visualization for their object in our UX

A way to allow for a developer to attach an arbitrary object to our Task objects

BTW we just added another Service API.

Now if we only wanted to support this one thing, we’re still not done…what do we do when the user clicks on that attached file?

We can decide that we just push them over to the developer’s server (it can be a straight URL). But that might be a bit of a pain to a user who’s just trying to read/learn about a specific task, right?

So we have to make sure we know the intent of our User Experience and then allow for a developer to participate in that intent. If our design intent is to keep the user in the Task/Task List to process things, then we need a way to let them see this file without leaving this Task processing mode.

Let’s say we want to let the user see this file/preview this file here — and we then have to design a user experience for how that will work and provide a way for this developer to extend that experience to inject their files.

What’s important about this task is that it’s got to align to our overall design intent for our User Experience because we are giving the developer access to that experience and we want the user to feel like it’s all the same design. We must also provide extension points so that the developer can achieve this.

And we also learned that through this process of understanding how to design for extending the User Experience we may impact the API design for the Service API’s. Failing to do this thorough analysis will create gaps and developers will not be able to provide the kinds of experience they want or we would want to allow. Far too often this aspect is just “assumed” and we design extensions in the UX independent of Service API design and then have gaps because we have not used our Design Thinking approach to create a holistic experience for the end user, and instead we’ve just focused on delivering a feature set. This fails the developer and we lose their innovation in our platform because we dropped the ball and it fails our users, because we lack enough of these sorts of valuable extensions, or worse, if they are added, we give them broken experiences.

Next time we’ll cover the last section of Product Extensibility, the Embeddable User Experience design.