Monthly Archives: September 2012


Integration. This word/concept similar to application, component, data, service and so many other concerns in the software realm: it’s often the case that there are N + M meanings floating around a conversation with N people on the subject. :-)

If you provide a portfolio of products to customers, integration is typically an important aspect of your offering. Do these products play well with each other? Can there inputs and outputs be combined into broader workflow, etc.?

Unfortunately I find that many integrations seems to be merely technical in nature–as if to answer “yes” to “can I technically integrate?” Much like answering “yes” to “do you know the time?” this strikes me as missing the point altogether.

Integrations must be about how should I deliver the right experience to my user. That is, integrations should be experience-driven.

So, what may be some of the signs that indicate a need for focused improvement?

  • Workflows that span across products involve multiple login experiences (interruptions).
  • Users are forced to deal with experiences designed for a persona other than their own.
  • Software concerns are not consistent and therefore are not intuitive (e.g. able to be reused spontaneously in new business contexts).
  • Integration gaps in product must be addressed via professional services, consulting or directly by customers.

Any of this sound familiar?

When I get involved in an integration-related project, I tend to think about the following layered concerns:

This approach involves:

  • an experience-driven focus on key business roles/personas and their workflows – user objective over product feature/function (seamless)
  • data and insight in context for better decisions and actions – mere hand-offs don’t add value (frictionless)
  • social as glue across users (relational) – provide others’ insights in context[1] to facilitate further insight and action

How do you view and tackle integration in your own products?

[1] e.g.

Activity Streams: Queue and Flow

Awhile ago, when I was working with a team on activity stream related experience, I found myself thinking about two distinct concepts: queue and flow.

Until I came across this information stream related article, I had forgotten to share these concepts (e.g. to receive feedback).

So, about queue and flow…

When I say queue I refer to things such as alerts, things that require actions, things that indicate workflow, dependencies, bottlenecks, etc.

When I say flow I refer to context for queued activities (tasks) and also context to realize new tasks.

Feeds and inboxes are simply expressions of queue and/or flow. For example, wiki change notifications, mail list subscriptions, etc. are flow-like. Emails sent to me specifically may be queue-like. Tools like IFTTT make it clear that rules (or recipes) can be brought to bear on activity streams.

Queues can form automatically/implicitly and manually/explicitly. For example, business rules may be met, causing an activity to enter one or more queues. A colleague may signal a dependency to a teammate (need cross-check, need assistance, need answer/insight to take own action, etc.), resulting in a queued activity.

Flow should unfold itself based on need to know. For example:

  • Meaningful default (last X activities, filters apply, time-based, etc.)
  • Ability to expand view–up to a point (e.g. Twitter handles roughly previous 8~10 hours)

As I mentioned briefly above, an activity in the Flow can become an activity in a Queue:

  • Alert someone else (as a notification with no dependency)
  • Alert someone else and subscribe to subsequent activity from that alert
  • Alert and realize own dependency on that task being completed

Anyway, that’s my brain dump on the matter of activity streams. How are you using them in your user experiences (UX)? How are you helping your users avoid information overload?