Tag Archives: XD

Experience Design (e.g. Adobe XD)

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.)

Realizing great customer experiences with LiveCycle ES3

Thanks to everyone at Adobe MAX 2010 who came to the sessions that I presented. I enjoyed the interactivity during after after the presentations, especially listening to your thoughts on how Adobe CEM will enable you to realize your own customer experience vision as well as the growing expectations of your prospects, consumers, customers and clients.

In order to keep the conversation going, I’ve uploaded this presentation as follows:

Realizing Great Customer Experiences with Adobe® LiveCycle® ES3 – Craig Randall

Whether you were able to attend MAX or not, I encourage you to check out MAX 2010 on Adobe TV (e.g. here are the keynotes). Please also visit the MAX 2010 session catalog to browse all sessions and download presentations of interest.

Update 11/5/2010: You can now watch and listen to this MAX session online (i.e. in synchronized fashion). It appears that the good folks at MAX decided to post the slides and recording that corresponded to my first delivery (on Monday during MAX). While that session went well, I did receive some feedback that I incorporated into a revised deck that was also recorded (on Wednesday during MAX). Personally, I liked the latter content and delivery better than the first, and that is what is provided here in this blog post, above.

Update 12/3/2010: Jayan has done a nice job of rounding up LiveCycle-flavored MAX sessions, including this one, here.

Subject To Change

I recently finished reading Subject To Change: Creating Great Products & Services for an Uncertain World, and I can recommend this book to anyone who wants, for example, to build software that resonates with its users.

Here are a list of thoughts and quotes this read produced:

  • Empathy is an understanding of a person or group’s subjective experience by sharing that experience vicariously that can be developed and cultivated through practice (i.e. it’s not innate). Using your sense of empathy can help you focus on the experience you want to deliver in a manner that is effective for those who will engage with it. Don’t confuse customer briefings with developing customer-focused empathy; there’s more to it!
  • Experience accounts for motivations, expectations, perceptions, abilities, flow, and culture.
  • Parity isn’t a strategy; neither is being the best.
  • Don’t craft the story of a product in isolation form the actual creation of that product.
  • Human life is complex–embrace this reality; don’t ignore it. Capture complexity with qualitative research (e.g. conduct interviews to elicit stories about experiences). Differentiate process (i.e. the how and why) from outcomes (i.e. the what, where, and when).
  • Sometimes experience strategy isn’t about hiding complexity as much as it’s about managing it (e.g. distribute complexity across a system so as not to overwhelm at any particular point). That is, the overall experience should never become too complex. There needs to be coordination among the experiences touch points, allowing each to fully exhibit its strengths.
  • “You have to recognize that a system will degrade, and make it such that such entropy doesn’t shatter the entire experience. The true success of experience design isn’t how well it works when everything is operating as planned, but how well it works when things start going wrong.” For example, provide meaningful seams into which people can insert themselves (i.e. leave an impression).
  • Great experience is difficult to plan for, and almost impossible to specify.
  • Good experiences require systematic coordination with the customer in mind (i.e. a focus on qualitative customer insights).
  • “Design is a way of approaching problem solving, decision making, and strategy planning that can yield better outcomes.”
  • “[Design-centric organizations] peer into the needs and desires of their customers, identify patterns of behavior, refine ideas that tap into those behaviors, then push into the unknown–or at least the uncertain.” -Roger Martin
  • “You can’t build a design competency overnight; it requires difficult changes in process, skills, and perhaps most importantly, culture.”
  • In my development organization we deploy a risk-driven iterative development process, with phases we call inception, elaboration, construction and transition. I’d liked the book’s description of “the fuzzy front end,” which I would liken to inception (e.g. “anticipation exceeds insight”).
  • “Good ideas need to fail early and often so you can arrive sooner at a great one.” Process won’t turn mundane ideas into stars–nor will great effort (strong execution). Therefore, avoid premature execution of an idea. For example, presuppose multiple solutions and suggest alternatives based on partial data. Define constraints that drive great solutions (e.g. think like a newbie, leverage empathy (that you’re developing, right? ;-) ).
  • “Strategy should bring clarity to an organization; it should be a signpost for showing people where you, as their leader, are taking them–and what they need to do to get there…. People need to have a visceral understanding–an image in their minds–of why you’ve chosen a certain strategy and what you’re attempting to create with it…. Because it’s pictorial, design describes the world in a way that’s not open to many interpretations.” -Tim Brown

On Monday, I noted 11 years with EMC (via its acquisition of Documentum). I can certainly say that “change happens” in the content management space and my own career.

My first engineering responsibilities were centered around the Documentum Desktop (aka Desktop Client) offering–client/server architecture implemented as a mixture of C++ and VB. Then I was called on to drive the first major release of WDK, a web-based application implemented in Java, JSP, HTML and XML. Next stop: creating an integration bridge between Documentum and authoring environments like Office, Adobe and XML editors (i.e. Application Connectors), which was specified as an N-tier architecture implemented as a mixture of C# (on the desktop) and Java (on the middle tier. Currently I’m focused on providing a rich set of services (i.e. local Java APIs, WSDL-based web services and RESTful web services) that drive a diverse set of applications, each with its own presentation layer technology decisions (e.g. Flash/Flex, ExtJS/DWR, etc.).

And “tomorrow” this will all be subject to change once again… :-)