Author Archive: Steven Webster

The Relevance of User Experience Design in eGovernment

I recently spent some time with the Adobe Government team to discuss how the ‘consumerization of IT’, and the increasing expectation of users to have simpler, easier and more effective user-centered experiences in the enterprise, is just as applicable to citizens and constituents in open and electronic Government.  We captured our discussions as a series of 3 interviews that the Adobe Government team are posting over the coming days.

In part one, we have a general introduction to the Technology and Experience Innovation team at Adobe, what constitutes a typical day for the team, and broadly, the importance of user-experience as we see it as a complement to technology expertise.  In the interviews that follow, the team asked me about the importance of user experience in government, the relevance to the Open Government Initiative in the United States, and what we consider the future might be for digital experiences in the enterprise and in government.

I’d love to take some dialogue and questions to this blog, and here your own thoughts and ideas!   The first part of the video is here.

Considerations for Design in the Enterprise

I arrived last night in New York, and am looking forward to presenting at the Adobe Partner Community Day.  Tomorrow, our focus is on the “front of the glass”, and User Experience Design in the Enterprise, and we are going to be joined by a tremendous number of our design partners.  On Wednesday, we shift perspectives to the “back of the glass”, where we will be joined by system integrators and enterprise development partners.

I’m very much looking forward to delivering a presentation I’m calling, “Considerations for Design in the Digital Enterprise”, which shares some perspectives on how to bring cutting-edge and courageous user-experience design alongside enterprise software craftsmanship, to create the most simple, effective and compelling experiences in the enterprise.  From “Be on the lookout for thoughtless acts; they are where innovation hides in the open” to “Look for the tension between business goals and user needs; that is where innovation hides in the dark” I’m going to try and open up several different considerations in the context of some of the more recent work undertaken by my own team, on behalf of Adobe and on behalf of Adobe’s most strategic enterprise customers.

I’ll be tweeting live from the event using KeynoteTweet, and a video of the presentation will be made available afterwards.  In the meantime, I’d love to hear what considerations you would share, for how to bring cutting edge user-experience design to the enterprise, and how to blend such design with mission critical software engineering.

Design is on the Enterprise Agenda

Several years ago, I was one of the early adopters of Rich Internet Applications as an opportunity, and would spend a tremendous amount of time in front of prospective customers, evangelizing the need for greater richness, expressiveness and simplicity in the experiences we deliver.  Macromedia coined a tremendous phrase that, “Experience Matters”, but the dialogue I would find myself in with enterprise customers was very much what Geoffrey Moore would call “Provocation Based Selling”.  Provocation-based selling helps customers see their competitive challenges in a new light that makes addressing specific painful problems unmistakably urgent – in the case of Rich Internet Applications, the unmistakably urgent problem was that we were failing to deliver on the promise of the Internet, and that application experiences took a step back from client-server to desktop to web.  I’d say over the last 3 or 4 years, evidence that the provocation towards early adopters is no longer necessary, and that there is now mass market acceptance of the need for richer user-experiences, could be qualitatively measured by the fact that I no longer have to provoke, I no longer have to say why.

Fast forward a little, and the dialogue in the enterprise boardroom was less about Why? and increasingly about Why Adobe?   And so in this phase of our enterprise maturity around more effective digital experiences, the conversation would move more towards “Flex versus Laszlo”, “Flex versus AJAX”, “Flash versus Silverlight”.  As executives understood the present problem posed by the provocation, they sought to understood the technology to anaesthetise their pain.

But if I’m honest, I rarely engage in that dialogue anymore.  Whether I visit a customer, or whether a customer visits me in our Customer Briefing Center, it is much less common for me to be engaged in discussion of technology versus technology.  However, there is a new provocation today, and it’s the most enjoyable one yet and it’s an incredible differentiator for success.  Technology is necessary but not sufficient…irrespective of the vendor selection to deliver a richer experience, the delivery of a compelling experience, one that resolves the dynamic tension between the ROI the business seeks, and the tasks and goals their users wish to achieve, is not a technology problem.

It is a Design problem.

I am incredibly excited at the opportunity to play a role in this provocation, and to observe in front of Adobe’s customers how the provocation is also moving the importance of experience design in the enterprise from an opportunity for the early adopters, to a necessity for the emerging mass market.  Though customers like Morgan Stanley may have had the courage, the insight and the balance sheet drivers through which they understood the opportunity behind the provocation, they have created a bar that their competitors and peers now either choose to bang their head on, or also take a new approach to clear.

The approach is Design-thinking, and the approach demands that software engineers, business analysts and organizational behavior embrace and absorb designers, and Design thinking.

I’m very much looking forward to a 2-day event in New York next week, where Adobe is bringing together it’s enterprise customers and developers with it’s community of design talent and design customers.  As Design and Technology collides in the Enterprise, we are incredibly fortunate and excited to have both of those communities available to us.  Consider joining us, by signing up at http://www.engagewithadobe.com/

I would also encourage you to read Rob Tarkoff’s post here.  Rob is the Senior Vice President of our Digital Enterprise Solutions business unit, and is really driving this collision of Design Thinking and Technology Innovation in our enterprise offering.

We’ve said it before, and we’ll say it again.  Experience Matters.  Business has never looked Better.

Flash Player is the #1 Free Download on Android AppStore

I grew up in the same town, and attended the same school, as the economist Adam Smith. Granted, we did so some 250 years apart. Adam Smith coined the metaphor, “The Invisible Hand”, in his book “The Wealth of Nations” .. it’s a metaphor about freedom of choice for consumers that I was immediately reminded of today when I saw Adobe Flash Player 10.1 sitting at the top of the Android Application store.

FlashOnAndroid.jpg

The theory of the Invisible Hand states that if each consumer is allowed to choose freely what to buy and each producer is allowed to choose freely what to sell and how to produce it, the market will settle on a product distribution and prices that are beneficial to all the individual members of a community, and hence to the community as a whole.

Investors invest in those industries most urgently needed to maximize returns, and withdraw capital from those less efficient in creating value. Students prepare for the most needed (and renunerative) careers. All these effects take place dynamically and automatically.

And consumers of mobile devices, when customizing their devices to maximize the experience they can enjoy and the services they can consume, are being guided by the Invisible Hand towards Adobe Flash Player 10.1

It’s great not only to see this initial adoption of Flash Player on Android, but to see it as a self-organization driven by the consumers of the experiences it offers.

Experience still matters.

Further Forrester Thoughts: Business Analysts versus UX Designers

Earlier, I posted about Mike Gualtieri’s recent Forrester paper (I should credit his co-author also, Mary Gerush), titled “Business Analysts: Seize The Opportunity To Deliver Compelling User Experiences“. From reading the initial abstract, I challenged the thesis that a Business Analyst can truly deliver the value that a user-experience designer can and committed to reviewing the paper in greater detail. I have, and I’ve engaged in some really interesting and thought-provoking dialogue with Mike, that I want to open up here a little.

First and foremost, if you are working in the enterprise, where I believe that user-experience designers have the opportunity to fundamentally unlock the value inherent in the digital enterprise, then I highly recommend subscribing to and following Mike’s research. I have spoken with many enterprise customers, where internal advocates for user-experience struggle to articulate value within a technology-centric organization, and Mike’s work is most definitely going to help you address the impedance mismatches that recur.

As I read Mike’s paper, I really enjoyed the setup; he does a great job articulating the importance and value of the design process, as well as the traits and characterists of the value that a user-centered approach brings to the enterprise.

My initial contention still remains (though I’ll also represent Mike’s position here, which softens my pushback a little) however.

Traditionally, Business Analysts would be responsible in an organization for creating business requirements for software products, these requirements would be captured in a specification/business requirement document, and these would be passed to an engineering team for estimation and implementation. Oftentimes, there is zero design featured in the process – and what design is involved is often “small d design”, that focuses more on adherence to style guides and templates, than the more fundamental value of (big D) Design that really seeks to deliver a product that more ergonomically meets the needs of users, as well as the needs of a business. The Design process hinges on user-centered design methods, most notably observation methods that inform the solution.

Mike proposes that to address this shortcoming, of little or no Design in the process, is to “give UX eyes” to Business Analysts, to encourage the armies of business analysts in the industry to learn to “see the world as UX designers see it”, to employ user-centered design methods (ethnographic research, user interviews, understanding personas, etc).

Here’s my concern; I think the value of the above-mentioned activities isn’t in their execution, but in the environment they create for a Designer to Design. While a business analyst might employ these methods, without Design in their DNA, I don’t believe they are going to get to the same solution and innovation as a designer…they may observe pains through the lens of a user, but it’s what they then do with them that concerns me. Or more specifically, what they don’t.

This process of Discovery is where I believe most of the magic happens in our application developments; it’s where we uncover the insights that reveal the “soul of the application”. These soul searchers are designers however, able to translate insights and observations into ideas.

Furthermore, I believe and advocate that “Requirements inform Design, but Design informs Requirements”. Innovation rests upon prototyping and “failing early”, and where we are most successful I believe, is where we immediately act upon insights with Design prototypes…as we test the success of these design concepts, they in turn drive features in the requirements. Rarely do these innovations emerge as interpretation of a requirement.

However, this is where I think Mike and I agree more than we disagree! I asked Mike if I could open up some of our dialogue here, I think the key comment he made back to me that opens up my thinking is this:

“Our premise here is that most application development teams don’t know anything about UX design. But, they are the very people who end up “designing” the user experience, usually by accident. So we are just trying to turn the dial a little bit in the right direction by getting app dev pros (in this case BAs) to start thinking about how they can pragmatically contribute to better UX in applications that their team develops. If we tell them it is important and to go hire a UX team, it won’t always happen.”

I think this really sums up my philosophical difference; I’ve been doing some work recently with Geoffrey Moore, and a phrase he often uses is “Crossing the Chasm in the Belly of the Whale”, which I would paraphrase as untethering an approach temporarily from the desired (ideal ?) end-state until you can drive it to scale, and then fold it back into the process.

As I relate these ideas, I think my position of “user-centered methods belong to user-experience designers” is the crossing of the chasm, while “business analysts should embrace user-centered design methods” is a tactic (and perhaps not the only tactic..) that can be employed today, while we are in the belly of the whale…

What’s interesting for me with Mike’s approach, is the scale that it offers…there are many more business analysts inside enterprise IT organizations than there are unfortunately user-experience designers. While I believe it compromises the end-product, is it worse than having no design sensibility at all ? I’m wrestling my own conscience here…

This whole dialogue has caused me to pull up some old presentations and papers that I started writing some time ago, as I was helping system integrators think about how they might bring user-experience design into their technology and business consulting practices. It was the idea of a “User Experience Capability Maturity Model”, that describes the spectrum of “UX maturity” within a team or organization, similar to the Capability Maturity Model (CMM) from Carnegie Mellon, formerly prevalent in software development.

I’m going to think more about that in the weeks ahead, as I think Mike and I may just be plotting a couple of points along the same curve.

Thoughts ?

Recording available of “Intuitive Experiences with Flex and SAP”

Earlier this month, Matthias Zeller and I presented on “Intuitive Experiences with Flex and SAP”, at SAP’s community event in Palo Alto. The presentation was recorded, and is now available here (we start presenting 24 minutes in to the presentation).

In this presentation, we showcase Project Hendrix at Adobe, we talk about the importance of Design in technology, we talk about how to build Flex experiences upon SAP implementations, and we introduce the idea of Experience Oriented Architecture.

I’d love to hear what you think.

XOA Traits: Coarse-Grained Experience Components

The notion of fine-grained versus coarse-grained services is an oft-debated topic in SOA; if you take a look at this paper by IBM as an example, you’ll see how terse this discussion is, and how completely in absence of the end user of the software application it actually is. I’ll refrain from the debate.

XOA suggests that service granularity, and the services themselves, emerge from the needs of a presentation tier component, of an “experience”. Rather than hypothesize on the services we might want to expose in our banking systems for instance, we allow the user-experience of the application consuming the services to dictate the service, and the parameters/interface/signature of that service.

I recently presented on XOA to some of the innovation team at Credit Agricole, and they shared a great anecdote which I told them I’d use, and they allowed me to credit !

In the design of a service for transfering money between 2 accounts, the IT organization put a check in place in the service…if the account from which the transfer was being made didn’t have sufficient funds, the transfer did not take place. However, there was a very specific use-case from the broker team, where they needed to be able to transfer money from an account that was overdrawn … however, the use-case only revealed itself in the design of the end user-experience, and was never envisaged by the SOA architects. The consequence — no re-use, 2 services created, one of which is a more generic instance of the other, and now code to maintain in 2 places if business rules change. It’s a trivial but real example.

In an Experience Oriented Architecture, we would create a reusable component – in my world, this would be in Flex – that delivered the best imaginable experience for moving money from one account to another.

The component would encapsulate all the design findings from the user-experience team; it would provide visual affordance if the transfer was going to overdraw one particular account as a consequence, it would give meaningful feedback as to when the transfer might take place, or the duration of time for the transfer, it might also look at pending transfers in both accounts to inform that “though this won’t overdraw you right now, by the time the transfer takes place, this cheque will have cleared from this account and you will be overdrawn…do you want to instead transfer on this date, transfer less money, or also move money in from elsewhere to cover the cheque”.

In support of this enhanced, user-informed experience, is most likely some complex choreography of back-end services, most likely some horizontal integration of different back end systems (another trait of XOA I believe … for another day) and some implication to the SOA team on the services that need to be exposed in support of the user-experience the user deserves.

There will of course be complexity involved; the back end systems might include integration between different banking systems …. for a bank (such as Royal Bank of Scotland) that has 2 underlying banking systems as a consequence of a merger between 2 banks (RBS and Natwest), it might be the case that some accounts hold transactions in a CICS mainframe, some in an Oracle 8i system on the other side of the firewall, and the balance checking in both systems is different.

However, the contract with the application developer is “use this Flex MXML component, style and skin it according to the Flex programming model, and implicit in the reuse of this component, we will handle all of the underlying complexities of LiveCycle Data Services integration across CICS mainframes and Oracle 8i, and the nuances of balance transfer across the firewall, or within accounts”.

So XOA drives out coarse grained components (“An Account Transfer Component”), and these components handle the complexity of choreographing and orchestrating underlying services. And as a consequence, the decisions around which services are required, and the interfaces/signatures upon those services, is driven from user-needs, not from Business or IT.

Traits of an XOA (Experience Oriented Architecture)

As the phrase and philosophy of “Experience Oriented Architecture” (XOA) is capturing attention in the halls of San Jose at Adobe, particularly amongst our technical services organization and enterprise business unit, I find that I want to more concretely define what I mean when I think about XOA. It’s leading to a lot of interesting debate and dialogue that is promoting some of the SOA conversations of old, to XOA conversations of new…coarse grained versus fine grained, loosely coupled versus tightly coupled, etc. So let me share some of my own thoughts, on what traits define an architecture as “Experience Oriented”.

Let me start from my original premise – that of XOA as a way to address some common failures of SOA initiatives by taking a more user-centric approach to driving out services and architecture.

Addressing the SOA failure of reuse with XOA

So one of the cited failings of SOA initiatives is the disappointment in the ROI that was anticipated around re-use. SOA contends that by driving out a service tier, these services will be reused by developers across different projects. However, this is tightly coupled to another SOA challenge — too fine grained a service, and the reuse is wrapped up in a whole bunch of bespoke effort, too coarse grained a service and the reuse doesn’t happen because of the specificity of the service. The tension between fine and coarse-grained services is palpable.

So here’s the first traits I see for XOA:

  • Coarse Grained Experience Components
  • Implicit Choreography and Orchestration of Fine Grained Services in the SOA tier

I’ll take them up in another post; though I’d appreciate your thoughts and comments…

Can Business Analysts become User Experience Designers ? Forrester thinks so…

I met with Mike Gualtieri of Forrester earlier in the year, at the Adobe Industry Analyst Summit, and very much enjoyed discussion around the role of user-experience designers in creating user-centric solutions in the new enterprise. I note that Mike has just delivered a Forrester Whitepaper, titled “Business Analysts: Seize The Opportunity To Deliver Compelling User Experiences”.

The abstract for the paper follows, and if I were to just read the abstract I think I’d take an opposing position to Mike in the paper:

“Is anything more important than how users experience your Web sites and software applications? If your customers can’t effectively and efficiently meet their goals by using your sites and apps, they will go elsewhere, leading to lost revenue and increased expense. If employees find sites or apps too hard to use, they become frustrated and less productive. To maximize productivity, smart organizations place a strong focus on user experience (UX) as part of the software development process, but not every firm has people with the right skills and focus on this important discipline. This is a great opportunity for business analysts, but it requires a shift in the way they define requirements. UX skills are often absent from business analysts’ (BAs’) tool kits, because BAs have been trained to engage “the business” to learn about requirements but not to do true user research that will deepen their understanding. By gaining key skills, performing user research, and actually “becoming” their application’s end users while defining requirements, BAs can improve the user experience — and organizational outcomes — by helping create apps that are useful, usable, and desirable.”

I look forward to reading the paper in further detail, but here’s my concern….I’m often asked, “how do we train our technical team to do the design work” or “how do we teach our business analysts to do the design work” and my answer is always an initially flippant but somewhat heartfelt, “4 years of Design School”.

You see, Design is a profession…and I think we have to be incredibly careful in removing Designers from the Design process. At surface level, there are techniques employed by designers that unravel and reveal the insights that will inform a subsequent design…user interviews, creating user personas, ethnographic research techniques that allow observation of end-users engaging in existing processes with existing tools, are all means by which an experience designer can try and find the “soul of the solution”, the key insight or insights upon which an improved design might emerge.

I struggle initially with the idea that by taking these techniques away from designers, giving them to business analysts so that the analysts write better requirements (through the lens of the user), that a better user-experience will emerge by giving these requirements (now informed by a user) to a designer to create a new user-experience.

For the methods exist to create the opportunity for observations and insights; there is questionable value in the persona as a deliverable, as much as there is value in observing and generalizing user behavior according to tasks and goals, for instance.

I look forward to reading Mike’s paper in full, to better understand the research…however, my own thinking would be that rather than “make designers of analysts” we recognize that before we specify how to “build things right”, we must employ designers and their design-thinking to ensure we are even “building the right thing”. And once we have reframed the problem we are solving through the lens of the end-user, I would hope that we can find ways by which requirements are informed by designers, and designers are informed by requirements, through process and approach that brings the requirements gathering process and the design process together.

That’s the 3D methodology we employ within our Adobe Technical Services Organization, a means by which we partition the process of Discovery from the process of Design, and setup the appropriate handshakes rather than handovers between the different skills in these cross-functional teams.

Are there other industries that you know of where we take the Design process from designers, and give it to those who specify the features and functions of a product or service ?

Recording of “The Value of Creating Intuitive User Experiences”

A recording is now available of the presentation Ron Rogowski and I presented for the Adobe Webinar “The Value of Creating Intuitive User Experiences”.

As part of this presentation, I demonstrated “Project Hendrix”, an application that my team has been delivering internally within Adobe to allow our support staff to help more customers, first time, in less time, every time. The application is a Flex experience delivered upon a complex enterprise architecture, most notably SAP CRM, and leveraged our user-centric 3D Methodology to discover the insights, to inform the design and requirements of the application that was ultimately delivered.

Enjoy the recording here.