Tag Archives: CX

Customer Experience

Modularity without modules…what’s the point?

If you follow me on Twitter, you might have an idea that my son is currently without one of his rides (i.e. a Razor Cruiser kick scooter). My son is big and tall for his age, and this scooter is perfect for him.

Like most boys his age, though, he doesn’t understand “cruiser” in the face of a neighborhood of boys who all like to jump all manner of wheeled vehicle. :-) As a result of this lack of appreciation (er, love of both scooter and jumping), what looked like

Unridden Razor Cruiser kick scooter

now looks like

Used Razor Cruiser kick scooter front assembly

Failed wood/fiberglass Razor Cruiser kick scooter deck

Failed wood/fiberglass Razor Cruiser kick scooter deck (close-up)

Used Razor Cruiser kick scooter back assembly

Do you see the opportunity?

Razor makes a quality product–one the is easy to use and maintain. Ease of maintenance is largely facilitated by modularity of design.

So when my son came to me with the disappointment of pushing his ride too hard, my first thought was to simply disassemble the scooter to isolate the failed part (deck). Easily accomplished.

Except that apparently Razor and its authorized parts retailers doesn’t stock replacement decks for the Cruiser kick scooter.

So…Razor built a modular kick scooter but doesn’t stock a critical module (deck).

What’s the point of modularity, if there are no modules (i.e. ability to swap module instances that fulfill necessary interfaces)?

My son’s predicament is clearly of his own making, but herein is opportunity for Razor. Beyond already clearly stating what their product is designed to perform, Razor can anticipate that boys will be boys and provide timely relief in the form of complete replacement parts, including readily available decks.

Within earshot of my son are more than a dozen boys of similar age, and they’re always outside planning their next jump. Many already own their own Razor, too. What if he could turn around an accident with word that Razor saved the day? Talk about brand advocacy and social media!

What’s your Razor-like story? What’s your Razor-like opportunity?

The Experience Architecture

In my #AdobeMAX session today, I presented a set of experience architecture principles with my colleague Marcel Boucher as follows:

I’ve gone into greater detail about these principles in a technical white paper that is available from the Adobe Enterprise Developer Center as a PDF download.

During our session, Marcel presented two demonstrations:

  1. The first demonstration featured an overall vision for customer experience in the retail banking domain. If you weren’t able to catch this demo live, you can see it presented here during the FinovateSpring 2011 event.
  2. Marcel’s second demonstration provided more of the how behind the vision in terms of Adobe’s integration across its Web Experience Management (WEM) solution, SiteCatalyst and Test&Target. A video similar to Marcel’s demonstration of this integration is available here.

MAX is always a great event, and the enterprise team at Adobe is looking forward to sharing more with you about Digital Marketing at our upcoming summit in March 2012.

What is XOA?

XOA stands for experience-oriented architecture. XOA was first coined by Adobe’s Steven Webster “to very specifically mean applying design thinking to evolving an architecture stack, and more recently, to talk about instrumenting an experience in order that it can be measured and monitored as delivering against intended KPIs.” It is therefore incorrect to reduce XOA down to component development. At its heart, XOA embodies best practices for RIA development, whether in the browser or on the desktop.

In the (just-announced) Adobe® Digital Enterprise Platform, XOA manifests its RIA best practices via layers (concerns) as follows:

  • Presentation – view rendering
  • Domain – client-side computations, abstraction of server calls, etc.
  • Infrastructure – server communication

XOA is an architectural approach and is not bound to a particular technology (e.g. applies to Flex, HTML5, native mobile, etc.). XOA is certainly not meant to be a formal label–just like you wouldn’t expect to see “SOA” in XML, etc.

This layered architecture [1] provides an efficient way of segregating the code related to view rendition, client side computations, perpetual asynchronous communication, etc. Embracing such separation of concerns enables ADEP development projects to be easier to understand and to manage. Moreover, it helps developers with different personas to work in tandem on a component (e.g. the UI developer in concert with a business logic developer).

Example of applying XOA to ADEP-based Flex development: Enterprise Flex components (aka UX (User Experience) Components) are mostly data-driven with data synchronizing from a backend server over Remoting, Data Services, etc. With data coming from server in an asynchronous fashion and component assembling itself by computations, the complexity increases manifold since the component, apart from rendering itself also needs to construct itself. Therefore, it becomes extremely important to separate concerns before the component development turns unmanageable. However, please keep in mind that XOA is about much more than component development as noted above.

For example, a UX Component in ADEP is an enterprise Flex component that embodies XOA principles.

More on UX Components and other aspects of ADEP in future posts…

Update 6/30/2011: “What is a UX Component?

[1] You may recall that I spoke about XOA during my MAX 2010 session, “Realizing great customer experiences with LiveCycle ES3.” (ADEP replaces “LiveCycle ES3.” ADEP is the new brand that incorporates aspects of LiveCycle with aspects of the Day Software aquisition.)

Thoughts on social software

Social is a popular adjective in software these days (along with cloud and mobile); so, I thought I’d capture some of how I view social in light of enterprise software and customer experience.

Footprint in the sand

When I think about “social software” I think about how experiences are impressionable (e.g. customers can leave impressions causing other direct/indirect participants to learn/benefit/dialog/collaborate). To me, “social” means allowing users to leave impressions such that impressions are mined for context and understood in context. Software that embraces this notion of sociability becomes more context-sensitive as a whole much like a piece of UI might present or hide itself depending on context (e.g. user’s role, workflow state, etc.) or a different service is invoked depending on context (e.g. SLA).

To me, “social software” isn’t about simply sprinkling social artifacts into existing systems (e.g. adding tags, ranking, etc.). It’s about ensuring that software incorporates sociability into its equilibrium as presented to customers.

One hears “less is more” and “more is more.” I find that both can be true, and the user will ultimate indicate the truth. In the case of providing more context, a user action to exclude is social to the underlying system, if that system is built to recognize it as such. That is, being exclusive is part of being social; excluding (and including) is a form of engagement. “Social software” must promote engagement–for relationship-based business benefit.

Being social can mean being friendly (i.e. sensitive to past expressions of preference, a form of context, as well current inference of the task at hand in a framing goal). A context-sensitive platform should go beyond just facilitating “one degree of friendliness.” It should anticipate the implications of deeper…collaboration. When a compelling experience and frictionless interaction is delivered to one, it can become a beacon for many subsequent experiences and interactions. So, how can this downstream effect be understood up front? How should context-sensitivity adjust, pivot, etc. to optimally understand this potential (reality)? “Social software” get this at its core.

Social is about collaboration–with purpose. To understand/infer purpose requires being sensitive to context.[1]

My definition of being social is as follows: a software system that allows any user to leave an impression, expecting that the system will recognize it, understand it and subsequently bring it to bear on the resulting experience, across space and time (i.e. same customer and/or different customer(s), immediately and/or in the future). This is just one of the traits we’re building into our enterprise platform at Adobe.

[1] For more on context, you may want to check out what my colleague Ben Watson has started over at Contextography.com.