Archive for March, 2010

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

Posted on March 9, 2010 by Steven Webster | Comments (0)

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.

Work for Adobe building Great Experiences out of California!

Posted on March 5, 2010 by Steven Webster | Comments (0)

As we build out our capability to deliver innovative, customer-centric experiences with our platform technologies upon our enterprise technologies, we’re creating a Solution Center in our San Jose office. The solution center is an incredible innovation-space, where a team of designers, developers and quality engineers will work together to create incredible experiences alongside Adobe partners, on behalf of some of our most strategic customers.

If you’re a developer, designer or quality engineer that thinks they could be a pivotal part of this initiative, then please check out Peter Martin’s blog post and drop him a note.

Note for Recruiters
Please don’t email me or call me … I’ll set expectation now that I won’t respond. I’m the messenger, not the hiring manager.

Great UX meets the Cloud and the Semantic Web….

Posted on March 5, 2010 by Steven Webster | Comments (0)

Last month at TED, Gary Flake showcased “Pivot”, which is an incredible visualization approach to navigating large sets of data on the web. If you’ve seen the Seadragon demonstrations before, you’ll recognize this as a novel application of Seadragon. There a number of reasons this demo catches me – it’s a weaving together of so many things that are current for me right now, namely innovation through user-experience design, thinking about Cloud technology as a platform for innovation and the Semantic Web as a trend upon Cloud technology that is going to fundamentally alter our ability to transact on the web.

First of all, I just recommend that you invest 6 minutes of your life in watching the video. What really stands out for me here, is the experience of “the content is the data” and the opportunity to directly manipulate the data as you drill into the data set. As we start looking at gestural interfaces, it’s clear that the ability to quickly move through a data set in an intutive, engaging and revealing fashion is quite literally at our fingertips.

I think when we reach behind the glass from the user-experience, we recognize that this is a great example of one of the vectors of innovation that Kevin Lynch often talks about, “Client and Cloud”. That this rich client is able to sit atop platforms of information that exist in the cloud (such as Wikipedia), presents incredible value to such an application. However, in order to be able to offer this kind of navigation in the cloud, it requires that there be some structure and meaning to data that is presented there, and some ability to draw inference between relationships between data that exist in different clouds.

Inferring meaning about data (and particularly data in the Cloud) is a key research topic in the Semantic Web, while being able to connect and move data between clouds is also an emerging challenge that there is huge opportunity to address. I’d like to talk about disparate clouds, moving data across clouds, sharing data between clouds, and “Interclouds” in another entry…but for now, let’s drill a little more on the Semantic Web.

Inferring data about data

If you follow through some of the comments from viewers, a shortcoming that is pointed out (and this is still just a research project) is the need for all of the data to be tagged effectively and accurately, and with cross-referential tags. For the demo at TED, it’s expected that the data was pre-organized and tagged; for this to reach mass market, we’d need to solve that problem in a more scalable way.

If you want to read more about the Semantic Web, I’d highly recommend “Pull” by David Siegel as a clear and detailed guide to the Semantic Web, and the opportunities it presents. The Semantic Web – being able to infer meaning about content and from that meaning enabling a fundamental transition from pushing information to pulling it.

David talks about the difference between “Content” and “Data”, and that the only thing that isn’t metadata, is content. When we think about the content that we produce, whether that be documents, videos, photographs, manufacturing drawings, there is “Format” metadata that can be automatically attached at content creation time.

For a photograph for instance, we see a tremendous amount of metadata attached by digital cameras through an interchangable and agreed upon data format, EXIF. By tagging photos at content creation time, EXIF allows us to record date and time information, camera settings such as aperture, shutter speed, focal length, shutter time and ISO speed, as well as thumbnail images. Over and above EXIF, camera phones can geotag a photograph, recording geographic position of a photograph, so you can unambiguously capture where a photograph was taken.

The bigger challenge facing the semantic web, is what David calls “Content Metadata”, which by definition is more about the meaning of the photograph. You may have taken the photograph in Paris on a Nikon camera on Thursday afternoon; but how do you record who is in the photograph, that it’s a photograph of Notre Dame, that it’s a fashion shoot for a particular magazine, the name of the models in the shoot and the particular clothes they are wearing ? That’s a much richer tapestry of data about the content, that enables the more powerful searching and exploration that Gary’s Pivot demo shows.

We see some attempts at post-processing of content to extract content metadata; for instance face recognition in photos such as the work startups like Face.com are undertaking.

However, I think if we look at how the problem of format metadata was solved, we have a clue to how we can also address these problems for content metadata. At content production time, the metadata likely exists in some other format, in some other tool. The fashion photographer has likely booked their models, booked their wardrobe, described where and when their shot is taking place and who that shot is for. They may have sourced the clothing from a particular retailer, and the retail information for that clothing also exists, including colors, materials and perhaps even inventory. If we think about how we can capture that metadata in the tools that are used at the most early phases of content creation, and if we think about the ways in which that metadata can be preserved throughout the content creation and production process, then the final content can collect metadata throughout each stage of the production and creation chain.

When that data appears in the cloud, it can appear with meaning.

I’ve talked about photographs, but this applies in all other opportunities around content creation. Videos start with storyboards, describing actors, locations, camera angles, lighting and shoots. Manufacturing begins in CAD tools where materials, colors, weights, etc, are all recorded … but that information often becomes discarded or lost as a 3D model of a shoe becomes a flat comp in Photoshop becomes a JPG on the web.

I believe there’s an enabling technology for the semantic web, which is working our way from back to front, all the way to the beginning of the content creation process.

Summary

Gary’s demonstration of Pivot is a fantastic user-experience; direct manipulation of the content presented as the data, the ability to move seamlessly from trends and representations all the way to the very content itself.

However, powerful experience on the glass depends upon power behind the glass; the Cloud and the Semantic Web are as fundamental innovations as the innovations we are seeing in user-experience design delivered on the Web.

To bring this back to Kevin’s Vectors of Innovation, it’s the relationship between Client and Cloud. What’s exciting to me, is what emerges when we innovate on both sides of the glass.

Deliver: Agile Execution aligned to Innovation

Posted on March 2, 2010 by Steven Webster | Comments (0)

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…!

3 Steps to Innovation with Adobe Experience Design and Technology

Posted on March 1, 2010 by Steven Webster | Comments (1)

Through a series of posts, I’d like to share ever increasing detail in how the technical services organization within Adobe – comprising user-experience designers and technologists from technical sales and solutions engineers to consultants – consistently approaches the ideation and implementation of solutions upon Adobe technology. Each solution that we innovate follows 3 steps, which we call our “3D Methodology” – Discover, Define and Deliver. Over a series of entries, I’d like to elaborate on each of these steps, as a prelude to sharing more deeply some of the best-practices that have emerged for us from repeated application of our approach.

When I describe “Discover, Define, Deliver” to customers and partners, I find it easiest to describe it from the back to the front…and so this is how I’ll introduce each phase over the coming days:

Deliver: Agile Execution aligned to Innovation

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.

I’ll talk more about agile development, the adoption of Scrum, and the traits of innovation methods that I believe align with traits of agile software development methods.

Define: where Requirements inform the Design, and the Design informs the Requirements

The industry has long accepted the fate-sealing that occurs when a project commences development/delivery before requirements have been adequately specified. In the 3D methodology, the Define phase commences when we feel we have gained enough insight and observations about user-needs, technology opportunities and strategic business drivers, to have a solution set of opportunities that can be elaborated with the customer into a set of business requirements.

I’ll talk more about design-led innovation, about how we bring together user-experience design methods with agile software development, and resolve tensions that so many of our customers and partners seem to face when bringing design and development teams together. In other cases, we find that there is tremendous lip-service paid to the design process … it’s something we feel strongly about, and dialogue we look forward to entering into in this forum.

Discover: gaining the Insights for Innovation

If Define and Deliver answer the question “how do we build things right’, then Discover answers the question “how do we build the right thing”. In our discovery process, we very much embrace innovation techniques and user-centered design methods that uncover the critical insights that ignite the spark and uncover the soul of an application. In the discovery phase, it is our goal to construct a portfolio of ideas to inform the very requirements that we collect with our customer to gather. These insights come from observation of the very individuals for whom our solutions will be in service.

I very much look forward to sharing our thinking and approach, the tools that we use, the assets that we create, the workshops that we facilitate and the philosophies that guide us in truly stepping back and challenging not just the solution, but the problem itself.

The 3D Playbook

We’ve captured this methodology as a series of individual plays in our “3D Playbook”, a social platform for capturing best-practices in how to set up for success. Should a project wish to, each phase of discover, define and deliver can be followed “by the book”, giving project teams clear guidance on the sequence of workshops, activities and deliverables. Alternatively, a project can be less prescriptive, but embrace the best-practices and philosophies that the plays are there to support, cognizant of the consequences of the plays that are being passed over.

I very much look forward to dipping into our playbook, and sharing with you our approach, the tools we use, the techniques we apply, and the lessons and learnings that we try to pass from one team to another at each stage in the innovation lifecycle.

Summary

We fundamentally believe that solutions delivered upon Adobe technology can establish the state of the art, can set the bar, where the technology is a medium and a means to an end, rather than simply the end itself. If Adobe technology is necessary but not sufficient, then sufficiency comes from the introduction of Innovation, and Innovation is Design-led.

Innovation doesn’t happen “by the numbers”. However, the environments that must be created, the individuals that must be engaged, and the insights that must be gained, can be sequenced and repeated. The practices can be repeated, and the best of these practices can become best-practices. Discover can yield insights for innovation, Define can bring the design and engineering disciplines seamlessly together and Delivery can assure a consistent execution with engineering best-practice.

I’m very much looking forward to sharing in this thinking, and entering into broader dialogue with our customers, partners and community about where we can share more, and what we can learn from the successful implementations that you are each responsible for delivering.

What else can we share ? What do you have to share with us ? Where do we begin ?