Home » projects » AppConnect

AppConnect

IBM cloud

Summary

AppConnect is a SaaS product for “citizen integrators” to connect systems, devices and apps and to automate, sync and schedule actions. 

Design team

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

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 competitive analysis and product definition, user research, interaction design, and accessibility compliance.

TL;DR

Line icon of a warning triangle with exclamation point

WHY: The problem

Connecting / collating information from multiple data sources and teams is slow, painful, and confusing.

Line icon of a pencil on paper

HOW: The process


This project was whitespace for IBM; we used generative research to define the project.

We then used SCRUM, LeanUX, and hypothesis driven design backed with both quantitative and qualitative research. We used prototypes and early releases to measure, learn, and iterate.

Line icon of a check mark in a circle

WHAT: The solution

A Freemium born-in-cloud productivity tool that scales to enterprise power and complexity.

Problem statement

This project began as a “hunch” by a senior business leader. My team was first tasked with finding out if there really was a business problem worth solving. This is the problem statement we drafted after completing foundational research.

Persona

Our target user is Cassie, a digital marketer who works at a small agency. She needs to track results but digging deep into the data with tech tools makes her skin crawl. She wants to spend more time creating and less time processing data.

What Cassie wants

During her day-to-day Cassie is kept busy by the actions of coordinating specific campaigns. She wishes she could spend more time understanding the deeper implications of existing engagement data. When she identifies a creative idea, she wishes it was easier to work with other teams to make it a reality, not a daydream.

Some of the things Cassie wants to be able to do:

  • Help me track social penetration
  • Help my customer support team be more responsive in social channels.
  • Give me the info I need so I can be prepared for my weekly meeting without having to arrive to work early
  • Keep two teams using different technology synced with the same data.
  • Have up to date phone contact details for all my key leads. 
  • To give my CEO regular updates on our sales activity. 

Our promise to Cassie

focus on the work that matters to you
by automating the work that doesn’t

Hill

This is our “hill” — a statement of who our product is for (Cassie, not an integrator), what they will do (join apps), and wow — the value the tool provides (within minutes)

Cassie isn’t an integrator, but within minutes of finding AppConnect she is joining apps in a way which she believes will help her be a better marketer.

Learn more about using Hills in IBM Design Thinking

Create a Flow

Cassie begins by clicking the create new flow block on the dashboard. We originally thought that the create flow block should be at the end of the set of existing flows, but customer feedback led us to place it at the very top.

The first step of the “create flow” task gives Cassie a preview of how she’ll construct her new flow. The navigation at the top identifies it’s a 4 step process. We tried many labels; the internal favorite was “connector” – the clear winner in user research was “flow.”

Cassie can select her first app from the list of icons, or filter on all the applications available to her. She already has Google sheets, Hubspot, and Twitter configured in AppConnect, so those float to the top of the list.

Cassie selects her second application, in this case Salesforce, the same way. The continue button (below the fold on this screen shot) becomes active once both apps are selected.

On page load, Step 2 sets up the metaphor of listen to (if this happens), and then do (take an action).

Cassie chooses from the set of triggers available for that app. The set of triggers are determined by the app integration author, in this case Google.

She selects the action the same way. Once both trigger and action are selected, she can continue to step 3.

Step 3 ensures that the selected apps are connected to Cassie’s AppConnect account. Some apps (for example, Google and Salesforce) enable connecting to multiple accounts; in those cases Cassie can select which account to use in this flow.

Step 3 also enables Cassie to map data between the two apps. For many actions this could be very simple; loading data into Salesforce is one of the most complex use cases.

Step 4 lets Cassie name her flow and confirm it’s doing what she wants it to. When she saves the flow it will be active. 

We started with “enable flow” as a label, and found in research that Cassie wanted reassurance it would be saved and expected it to be immediately enabled.

Cassie’s newest flow is shown as the last item in the flow list because research participants told us they thought about flows in the order they were created. 

We added the activity stream so Cassie can see all the actions she no longer has to do herself.

Process

Our design was driven through experimentation, feedback, and iteration. Here are some examples.

We started with mobile concepts. Very quickly we learned that Cassie wanted to monitor flows on her phone, but not create them.

When describing how to set up a flow, we used the concepts of a Trigger and an Action …

..and found out those words confused Cassie. She didn’t care how it worked. She just wanted to get something done. “Listen to …” “And then…” made much more sense to her.

Developers, on the other hand, loved triggers and actions. We used that terminology in the developer UI.

For the core of the flow design, we tried a visual data mapper. Cassie hated it. (By the way, developers loved it!) Instead we used form fields. Inserting field names seemed clumsy to us, but made sense to her.

Cassie told us the words we used were the primary way she decided if she wanted to try AppConnect… even when the structure, pacing, and images were identical. A simple thing like adding a tagline at the end of the first tour screen increased engagement.

This insight let us humanize IBM’s language and tone.

Post-launch

After I left IBM AppConnect went through several transformations and is now targeted at large enterprises across 4 verticals: Insurance, Banking, Healthcare, and Manufacturing.