Posts tagged "ux"

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 ?

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.

Experience Oriented Architecture (XOA) – Addressing the Failures of SOA

The concept of “Experience Oriented Architecture” (XOA) is really picking up momentum within the corridors of Adobe in California, as we continue to think about how we help our customers and partners create innovative customer-centric solutions for the digital enterprise. Though I have spoken about XOA in this blog in the past, I want to share more real-time the hallway conversations that are taking place as we align and define on what we mean by taking an experience-oriented approach to a technology project.

I first spoke about XOA at a Butler Group presentation in London, in July 2007, when invited to speak at a Service Oriented Architecture conference. The contentious position I wanted to take amongst a SOA audience, was that focussing on the SOA challenges like governance, fine grained versus coarse grained services, OASIS specifications and service bus approaches was fine and well, but it was missing the most important consideration in software development — that all of our efforts are in service of an end user, and that we must put them in the center of our approach.

To position this argument, I cited 3 of the acknowledged failures of SOA initiatives (in terms of not realizing the intended ROI), as taken from an Information Week article from March 2007:

  • Re-use (by creating a well-exposed service-tier, one hopes that services will be re-used more readily)
  • Business Agility (with a well-exposed suite of services, one hopes that others will be able to more rapidly deliver new products to market)
  • Alignment of Business and IT functions (with the service-tier arguably the exposition of the underlying IT infrastructure to support business needs, it could be argued that an SOA initiative brings these groups to the same table, and offers the opportunity for an alignment that otherwise can fail to occur)

I very much believe that the philosophy of Experience Oriented Architecture (XOA) can address these failures, by reframing the problem around users, not systems.

I thought a quote from Annrai O’Toole, the CEO of ClearCape, that appeared in the March 2007 edition of Information Age was apt here, “…unless you really understand what services you are going to create and why, there is no point in doing SOA. You must have a revolutionary approach.”

I believe that XOA, though simple in concept, is indeed a revolutionary approach to thinking about how to create innovative customer-centric solutions in today’s digital enterprise.

Do you know of any other approaches ?

Webinar on “Intuitive User Experiences”

On Wednesday 28 April, at 11am PT, I’m co-presenting with Ron Rogowski of Forrester Research on “The Value of Creating Intuitive User Experiences”. This online webinar will focus on the approach to creating user-centric applications, and the business value that emerges from intuitive user-experiences.

During this presentation, I’ll be talking about a project my team have been responsible for delivering over the last year, that is internally code-named “Hendrix”. This has been a tremendous collaboration within Adobe, bringing together our TXI team of technologists and user-experience designers with our IT organization, leveraging our 3D methodology for blending user-centric design thinking with agile software engineering, and in turn, creating an application that allows our agents in our contact centers to more effectively service Adobe customers – to help more customers, first time in less time. Every time.

Project Hendrix is something I am very much looking forward to talking more and more about in the days, weeks and months ahead…the business problem we were tackling (which has resonated with a tremendous number of customers to whom I have shown Project Hendrix in Customer Briefings in San Jose), the 3D approach we took to really understanding user needs, and how meeting user needs could meet business goals, as well as getting deep and dirty with the technical details of how we delivered an Experience Oriented Architecture … a tremendously complex implementation of a beautifully simple user-experience that leverages Adobe technology throughout the technology stack to attenuate the complexity of underlying systems such as our SAP CRM system.

It’s incredibly rewarding to have the project going live to our agents, and to be able to begin to talk about it with designers and developers, customer and community, and with the industry at large.

Sign up for the webinar here.

Why I dislike Devigners (and never buy fried chicken in Marin)

Take a look at this photo, of a sign that I drive past every single day…clearly someone at KFC decided that they could lift some stock imagery, adhere to brand guidelines, use the corporate approved font, and create for themselves a sign that would ensure that people honored the 1-way drive through system appropriately. I can’t say for sure, but it’s consistent with so many conversations I’m privvy to — we don’t need one of those designers, just give us the templates/some examples/some guidelines/some best practices and we can do the design ourselves. But seriously …. I wonder if there’s a correlation between the Colonel himself warning you not to enter his establishment, and the fact that I rarely see any customers as I drive past. I’m often asked “what’s the return on investment of design” – in fact I was challenged to address this question last year at Adobe’s Analyst Briefing in San Jose. My position was that you should really restate the problem as “what is the ROI that you believe exists in the solution you are developing; design isn’t a line item that delivers ROI of its own, rather than the process that unlocks the available ROI in the solution”.

kfc_donotenter.jpg

Because that’s the crux of it … if your problem is customer retention or customer acquistion, if your problem is shopping cart abandonment or number of customers who give up midway through a loan application, or if your problem is customer satisfaction for an online self-service experience, then you likely know your performance, and you have some sense according to industry convention or expectation, as to where benchmark performance is.

I wonder what would happen to the footfall in Mill Valley’s KFC, if “DO NOT ENTER” instead said “WAY OUT”, “EXIT ONLY” or “DRIVE THRU AT THE NEXT ENTRANCE !”

Once you understand that ROI that’s available in any given initiative, the Design process offers a much more user-centric approach to solving the problem and unlocking the ROI. While technology – whether that be Adobe technology such as Flex, AIR, LiveCycle ES, LiveCycle Collaboration Server, or another technology – may enable a solution that realizes the ROI, the design process is the difference between a solution built upon that technology that unlocks the ROI, and a solution built upon the technology that doesn’t.

Customers and partners will often ask me if our User Experience team can share some documents or papers that outline “UX practices”, or if we can create some “example screens” that can be used as baselines for someone without design in their DNA to cookie cut every other screen. When I’m asked this, I always think about KFC in Marin…about the logic that suggested that with some sample assets, some photoshop comps, some brand guidelines and the right fonts installed on the computer, customers could be steered in the entrance and out the exit in their droves.

For sure I’ve met some developers who happen to be incredible designers (they’re usually designers who manage to become developers, I think I’m yet to meet anyone who crossed over in the other direction) but they are the exception rather than the norm.

Design is a process, and designers are professionals that drive and participate in that process. I think the real opportunity isn’t to turn designers into developers, or developers into designers…it’s to find approaches, processes and methodologies that create the handshakes between the two, and to create tools (like Flash Catalyst) that facilitate these handshakes and workflows.

In the meantime, if you are working on a project, or with a customer, who is seeking “devigners”, or where “the business analyst” or “the project manager” is “designing the screens”, then maybe you should play a little chicken with them.

Deliver: Agile Execution aligned to Innovation

Previously, I spoke about “Discover, Define and Deliver” as the 3 Steps to Innovation upon Adobe technology. When describing this “3D Methodology” to customers, I find it’s easiest to start with that which is most familiar – Deliver – and then work back towards the value of Define and Deliver. When all is done, when the observations and insights have sparked an idea for innovation, and the innovation has been distilled into concrete requirements and designs, the Deliver phase is about bringing it all to life. It’s about breathing life into a design, lifting it from paper concept to production code. Deliver is primarily about writing code, pushing it through Quality Assurance and into production.

Deliver is agile…

Wherever possible, the team at Adobe advocates Agile development – and more specifically we advocate Scrum as our methodology of choice. This is indeed consistent with many of the product engineering teams within Adobe, as we more broadly embrace agile and Scrum within Adobe.

Formerly, I was an advocate of XP (Extreme Programming), but laterally, as more of the industry appears to embrace Scrum, as more of our customers embrace Scrum, and with more training and accreditation around the Scrum process, the differences between XP and Scrum are too trivial to matter. That previous link to Mike Cohn’s article highlights “Scrum doesn’t prescribe any engineering practices; XP does” … that being said, we very much advocate and encourage the practices of XP, whether it be coding standards, pair programming, unit-testing and test-driven development, continuous integration, and our teams are continually pushing the state of the art by contributing to tooling to support them, whether that be FlexUnit, FlexPMD, FlexPMD plug-ins, integration with Hudson, etc.

Prototype and Test == Release Early and Often

Throughout the 3D methodology, we strive to create the right environment for innovation. One particular trait of innovation is the ability to prototype and test; one particular trait of agile is release early and often. I think there’s a relationship between the 2 that is interesting.

Tom Kelley of IDEO talks about prototyping as “the shorthand of innovation”. I’d highly recommend reading that article, itself an excerpt from what we consider to be Adobe Technical Services required reading, “The Art of Innovation”. But within Innovation thinking, the importance of getting a working prototype in the hands of users, as a means of creating the opportunity to observe and feedback into the design, is very much established thinking. The team over at IDEO are tremendous at leveraging prototypes in their product design process; there’s a definite opportunity to embrace this kind of thinking and approach in the software product design process.

Within Adobe Technical Services, we will often prototype INCREDIBLY early in the process — oftentimes before we’ve even really undertaken a concise requirements gathering exercise. Prototypes are often deliverables from our Discovery phase, opportunities to explore hunches and insights, to play what-if with customers, or indeed even ourselves, and to stretch our own thinking about how some of the business needs, user goals and technology opportunities could come together in imaginative ways. We create incredibly high-fidelity prototypes, very quickly, either with Flash, with Flex or increasingly with Flash Catalyst…however, these vision prototypes really only take us on a “happy path” through the application. This kind of vision prototyping differentiates us from many others that we work with, and so I plan on talking about this in much more detail over another series of entries.

However, if you consider the agile process of delivering functionality in discrete time-boxes (what XP calls iterations, and Scrum calls sprints), then you recognize that each sprint affords us an opportunity to spin out a prototype that we can test. It takes courage on the part of the customer and the team, to challenge our own assertions mid-flight and to be prepared to course-correct upon learnings. But agile methods embrace change during development; and so the very engineering methodology that empowers us to prototype and test regularly through the development cycle, similarly empowers us to embrace the learnings straight back into the product design, during the manufacture of the design itself (which is in essence, the Deliver phase).

Deliver doesn’t have to be agile…but it helps…

We don’t always follow agile within Delivery, but ad-hoc is never an acceptable alternative. Oftentimes we will lead the delivery phase of projects with an Adobe team, but more likely we will be working alongside our customer’s development team or our ecosystem of Adobe partners. Agile approaches – stories as currency of requirements, feature-driven development and sprints of functionality prioritized according to business value – have proven to be a tremendous means of achieving technology and business domain knowledge transfer; I’d be interested if you have found the same also?

Summary

So when we get into the Deliver phase, we’re really in the midst of a software engineering lifecycle…there’s ongoing user-experience design for sure, but really the bulk of the experience is locked and loaded, in the backlog and ready for implementation. We definitely find that agile methods are conducive to innovation methods in the product design and manufacture, and so advocate them wherever possible. We definitely find that the engineering methods popularised by XP, and more widely embraced by the agile community, are as relevant to development with Adobe technologies as any other, and whereever possible we are contributing to and pushing the state of the art on the tooling to support agile engineering.

Most of the knowledge that we have to share in the Deliver phase comes from the tools, methods and best-practices particular to the technologies we are using, rather than the process or methodology we are using. Many of my colleagues are sharing this information in their own blogs and articles, and I’ll seek to reference them more in future entries.

However, as we push back into the Define phase, where a user-experience moves from concept to idea and to implementation, where we ensure that user-experience designs are satisfied by business and functional requirements and vice versa, where the real collaboration and magic happens between designers and developers, then I think we have a little more insight to share.

And so that’s where I’ll go next, with a similar overview of the kind of challenges we address in our Define phase. I’d love to hear what challenges you’re facing, how and whether you’ve addressed them, so that you might steer the direction of dialogue. By releasing these thoughts early and often, I have the opportunity to evolve them to meet consumer needs…!

Welcome to TXI

It’s somewhat of a habit, to post a blog entry with a leading apology for how long I’ve posted a blog entry…over a year in this case. However, it has been a tremendously interesting year at Adobe, building a team called “TXI” (Technology and Experience Innovation) of Technologists and User Experience Designers to deliver on a common belief that the most innovative and effective applications of Adobe technology, are the fusion of great user-experience design and great technology implementations.

You’ll know many of my team already, from the work they have already shared with the community — whether it’s technologists like Alistair McLeod, Peter Martin, Paul Barnes-Hoggett, Yaniv de Ridder, Francois Le Droff, or user-experience designers like George Neill, Jerome Doran, Kalle Korman, James Mellers or Dusty Brown. Along with their numerous other peers spread in our team from Romania to California, this team is responsible for really driving the state of the art in “what’s possible” with Adobe technology and design. In many instances, it’s in the solutions that we deliver for Adobe’s most strategic customers, in other instances it’s working with our partners and system integrators to help drive that thinking into their solutions, and in other instances still that team faces inwards, creating the applications and experiences that allow Adobe to better serve our ecosystem.

Along the way, we’re continually evolving how we think about bringing designers and developers together. We create tools, we derive techniques, we adapt software development methodologies like SCRUM to user-centered design techniques. We find ourselves deriving recurring patterns, whether these be software patterns, technology best-practices, or user-experience patterns that can improve interactions from one problem domain to the next. And it all culminates in the work the team delivers, and is proud of delivering.

I am missing an opportunity sharing our thoughts as we go, and collecting your thoughts along the way. And this is a tremendous vehicle for doing so.

There’s 4 things I care most about when I think about creating best imaginable experiences:

I care about Adobe technology; I truly believe that the phenomenal work of our product teams gives us the fabrics, the materials, the tools and the techniques to carve the most aesthetic, most effective and simple experiences, as abstractions to the most complex, robust and scalable enterprise solutions. And the more our technology platform matures, the more the world shifts to software that works the way people work, not the way systems work, the more experience matters, then the more I get excited about the opportunities we see not just to create effective veneers upon complex enterprise systems, but the more I see incredible integrations between our platform technologies and run-times, our creative products in the enterprise, our video and media products. Enterprise workflows, creative workflows, the seamless blend from virtual to just-in-time manufacturing, the production, protection and monetization of interactive media content, all present an incredible array of technologies from which to craft and carve solutions.

I care about Technology. More than just Adobe technology, but trends, directions, innovations and opportunities. Innovation is so often a product of cross-pollenation; taking ideas from one ecosystem and germinating them in another. Tracking trends and innovations in the wider technology ecosystem is the manner by which we ensure that we have the most advanced bricks and mortars to bring experiences to life; and as the materials we work with evolve, that in turns informs the experiences we are able to deliver. Design informs technology, but technology can also inform design.

And I care about Design. More than anything else. Technology is in service of the user, the customer, the citizen … it is necessary but not sufficient. Adobe has an incredible community of designers and creative professionals, and an incredible community of developers and engineers. The consumerization of IT, the trends in the industry from system centric to people centric applications, all bring mass market realization to the importance of Design in the software development process. This is something we are incredibly passionate about…we believe that design and development is a handshake, not a handover, and our people, our skills, our tools, our processes and our methodologies have evolved to bring these disciplines together (but not to create “devigners”, an inmate in disguise who still pulls strings in the day to day running of the asylum).

And all of this ? Adobe products, Technology trends and Design thinking ? To me, they are in service of Innovation. For that is what drives us, that is what keeps this team ticking, that is why customers engage us, why partners listen to us, and why in turn we enjoy immersing ourselves in our customers business, walking in their customers shoes, and understanding our partners opportunities. By bringing together our technology and design, we have an incredible opportunity as an industry to Innovate.

How can that not be exciting ?

So being the things that we care about as a team, these are the things we care about sharing. And in return, we hope to learn as much from you in return.

Where do we start ?