Connect & Compose

IBM cloud

Summary

My role

As the design lead I managed and directed a team of 6 designers and was accountable for both the quality and velocity of the design team. I partnered with the Product Management Lead and Engineering Lead throughout the process to ensure that stakeholders were kept up to date and all three disciplines were in alignment and on track to deliver.

I was a hands-on contributor to product definition, user research, interaction design, art direction, and accessibility compliance.

Connect & Compose is a service on IBM Bluemix, IBM’s iPaaS.* It enables API developers to: 

• create APIs quickly from a data source on Bluemix, the public cloud, or an on-premises / private network
• compose complex APIs from multiple data sources and perform operations
• publish their APIs to Bluemix and to the API Manager service.

Design team

• Design lead (me)
• Jr User Researcher
• Staff UX Designer
• Sr Ux Designer (2)
• UX designer / prototyper
• UI engineer

* Now called IBM Cloud

TL;DR

Persona

Will, a full-stack developer

Pain points

• Lack of communication tools between teams to respond to requests quickly.
• Spends a long time tracking the origin of crashes and how to solve the issue.

Solution

With Connect & Compose, Will can

Walkthrough

Core experiences

As this is was a new, Greenfield project we focused on designing these three core universal experiences for Will: Discovery, First Use, and Productive Use.

Scenario

There are three scenarios for Productive Use in Connect & Compose:

In this walkthrough I’ll show you the first scenario.

Create an API from a third-party cloud data source and share it to Bluemix as a User-Provided Service

Will can see on the Service index page the API he had created earlier. His task now is to create a REST API from his company’s Salesforce account and share it to Bluemix so the mobile developers can include it in an app for the Sales team. He starts by clicking the Create an API from a “Connection” button.

The page loads with a blank API template. Will can immediately see that he needs to choose a data source and configure a model in order to create an API. He notices that he will get swagger documentation, downloadable SDKs, and JSON for his API. The Connection and Model boxes are inactive.

Will enters a name for his API, and the Connection box becomes active. He clicks on it.

The service shows the list of connectors available to Will based on his Bluemix account; he wants to make an API from Salesforce, so he selects it and clicks next.

Will enters the credentials provided to him by the Salesforce administrator. Because he is creating a generic API connection, Salesforce requires he provide the client ID and secret for the primary account. Will clicks Test Connection to validate his credentials and his data source is connected. He clicks Finish and returns to the API template.

The API details template is displayed. Will sees that his connection details are displayed and the Model box is active. He clicks “Add a Model.”

The model builder screen shows all the business objects available to him.

There are hundreds of business objects in this Salesforce repository. Will knows he wants the Account object, so he starts to enter “account” in the filter. The service displays only the business objects whose name contains “account.”

Will selects the “Account” object and the data structure for that business object is displayed. He remembers from creating other APIs that he was able to select which data structures to include via checkboxes. His administrator has locked this business object so he must accept all the structures in the model. He clicks Finish.

The system displays the API template with the REST resources generated. He doesn’t want to use the POST method, so he disables that resource by clicking the X icon.

The POST resource has been excluded. This is not a destructive change; if Will changes his mind, he can re-enable the POST resource in his API. Will is happy with what he sees, so he clicks Finish API.

Depending on network performance the API creation process can take some time, so Will gets a notice that he will be notified when it’s ready. He is redirected to the API index page.

When the API is active, Will can quickly perform actions on my API via the gear menu. From the API index page he clicks on his new Salesforce API. The API details page is displayed.

Will sees that the base URL and API secret have been generated, and he can download SDKs and a JSON package. When he clicks on a resource the system displays standard Swagger documentation where he can test the API.

If Will wants to make the API available to other developers without requiring them to open the Connect & Compose service, he can share his API to API Management service and/or to Bluemix as a user-provided service. This time he wants to share the API to Bluemix, so he clicks that button.

The system displays a confirmation message. Will understands that he cannot edit the API once it is in the “shared” state. He continues to share the API.

The service updates the API details page with a confirmation and changes the availability status to “Bluemix.”

Will returns to his Bluemix dashboard and sees the Salesforce API has a service tile; it’s been published as a user-provided service.

When Will clicks on the tile he sees a version of the API details page; it provides his mobile developers everything they need to use the API without requiring that they open the Connect & Compose service.

Process

Iterate

We tested multiple design approaches to best align with our users’ mental model.

Some were refined, most were discarded.

The unexpected solution was “Mad Libs” which showed a skeleton of the whole process and made it easy to understand progress as the developer completed the process of creating an API.

Manage

Connect & Compose was one of four tracks in a larger program. While there were separate product management and engineering teams per track my team worked on all four.

The following is an example of a weekly “design share” process I established to keep all track leads and core stakeholders up to date. These weekly program status meetings were attended by executives from multiple business units.

Playback 0 is the first key milestone, where the team presents the business case and high-level concepts to executive stakeholders. At the end of the Playback 0 process the project is either greenlit as-is, cancelled, or re-scoped. A full design team works on the Playback 0, but developers aren’t assigned to the team until the project is a go. This design share was two weeks after the Playback 0 presentation.

The design team is shifting from high-fidelity concepts to detailed design anchored in development feasibility. One of my most senior designers (Tom) will shift to exploring the longer term vision, while I focus the rest of the team on the next release.

These are the “hills” for each track of work. For context, Connect & Compose is Hill 1.
For more information on Hills see my deep dive presentation

While the design team works on all the Hills, there is a separate set of stakeholders, product manager, and engineering team for each Hill, so we reported on each independently.

As we moved into implementation I changed the format of the Design Share to be more detailed. This meeting was recorded every week and the deck shared with all stakeholders.

Because this was such a large and complex project, collaboration across disciplines and across hill teams was incredibly important. We established formal comms structures including design office hours. All meetings were recorded, transcribed, and posted on Blueprints (IBM’s version of Confluence). Asynchronous communication was critical; while each hill team was roughly co-located, Hill teams were in multiple locations in the US and the UK. The design team was split between Austin, TX and Winchester, England while I worked from home in Philadelphia.

Each hill had multiple scenarios; we reported assignments by scenario so that product managers and engineers knew who to contact directly for questions.

We also had points-of-contact for “non-hill” efforts.

Much of my hands-on work was Hill 2; this next section is my squad’s progress since Playback 0

What Anna and I accomplished the prior week

A medium-fidelity exploration of the edit plan screen

A new module listing where the API is being used

A medium-fidelity rendering of a low-fidelity sketch shown in the last review

A process diagram for the scenario of adding a plan to a published service

Plans for next week for the Hill 2 design squad

Status for engineering re: stability of design deliverables so they can understand what is lowest risk to begin working against

Open questions – these are shared in the meeting but followed up asynchronously.

Every week we ended with blockers – this was a pretty good week!