UX Success

The Tripwire R&D Team celebrating product launch with Willamette Jet Boats - (The author is in the background getting hosed)

First the fun part — here’s what we do for team building after a product launch …….  a two hour speedboat ride on the Willamette up to the abandoned paper mill in Oregon City….

http://www.flickr.com/photos/65122491@N06/sets/72157627672561802

I’ve been reflecting on the Agile principal:  Responding to change over following a plan…

We have revolving-door UX sessions weekly with user surrogates face to face. We have 10 people who are committed to 15 minute sessions on the half hour every Monday. That way, we can divvy up the projects and each of the 3 scrum teams gets at least 3 sessions. We also swap our participants around to avoid fatiguing them with the same project. Generally, we are validating IXD concepts with Balsamiq Mockup click-thrus that represent our “happy path hypothesis” We record those sessions with Silverback. The UX person gives the report out immediately when the sessions are done and archives the recorded sessions so that we can do further analysis later.

Every sprint we strive to do one longer  session with Real Users — (customers who have signed up to be “UX Lab Rats”.  )  In a nutshell, these are 45 minute sessions — remote testing. I use WebEx and share an application — live code (working behind) or a prototype (working ahead). We record it — but also encourage developers and product managers to dial in (stay mute) and observe real-time.

This program has been the most influential in getting people to understand that what UX and UCD is all about — people using the stuff that we are building to solve their problems.

I believe the UX validation cycle be the single most important contribution we have made in working towards a delightful product experience for our users. Last week I got some feedback from the field that was  music to my ears.  A customer wrote a note back to the sales rep after upgrading and using the new feature :
“Side note — upgraded our console to 8.1 and am having an absolute blast setting up tag sets (and tagging profiles, to automatically apply tags).
It’s already giving me so much more visibility to the nodes.  LOVE IT! “

This is the kind of feedback UX lives for!   The success the field is seeing  is directly related to having UX sitting on those SCRUM teams  — designing solutions for developers to execute on – yes,  but most importantly, conducting consistent revolving door UX sessions with customers and folding their feedback directly and incrementally into the product — from lo-fidelity conception all the way through to code freeze.

here’s the link to the press release:
http://www.tripwire.com/company/news/pressrelease/new-release-of-tripwire-enterprise-delivers-smart-scaleable-and-strategic-security-configuration

In the six months that I have been working with my team – transitioning to an Agile development process and trying to figure out how UX fits in to the scheme of things,  I’ve recognized a need.    Our enterprise application development team  does not have a documented library of internal application interaction design patterns to be used as a reference for engineers.  This is forcing Business Analysts and Developers to design ad hoc interactions as applications are enhanced or refactored.  This practice is causing inefficiency in the design process and  inconsistency in the interface UI and interactions.  Here is what I wrote to the boss:

“Critical to obvious application interaction design is the element of familiarity – so that end users’ learning curve is decreased and productivity is increased. The discovery and documentation of design patterns, common interaction solutions to common interaction problems, is an emerging best practice for internal application development  efficiency.  Familiar patterns help users learn new applications quickly by allowing them to draw on their experience and use it while they learn new features and functions.  We know design patterns  emerge when a pattern proves to be effective over time.  When it works on one site, or application, others emulate the interaction pattern and when it succeeds across many common applications, users start expecting the familiarity of that type of interaction.

Unlike style guides and guidelines, patterns explicitly focus on context of use and tell the designer when, how and why the solution can be applied. Patterns capture a common structure, usually a very familiar one that is easy to recognize, without being too concrete on the details, giving the flexibility to be creative, unlike style guides.

Discovering  and then documenting internal design patterns will reduce the design time for engineers if we develop a reference point for them to  solve interaction design problems.  An added benefit  is  that this practice will  ensure consistency in the application user experience……”

He asked me how we would do this, and here is what I thought we’d try.

1. Discover existing interaction solutions to common interaction design problems found in web and mobile applications and document their use in an Interaction Design Pattern Format
2. Document anomalies to those patterns and make recommendations for improving consistency
3. Develop a searchable, scalable library of interaction patterns  for use throughout the enterprise

Just because I am a musical theatre geek and this tune has been running around my brain:

“I love you madly, madly Madam Librarian…Marian …”

Does anybody out there have any experience with this?

Will you share how  interaction pattern libraries have helped you in:

• Teaching best practices and common approaches by showing rather than telling
• Capturing collective wisdom of designers/developers  across many uses and scenarios
• Making usable designs the “path of least resistance”
• Eliminate wasted time spent “reinventing the wheel”
• Ensuring users have a consistent and predictable experience within an application or service
• Giving teams a common language, reducing misunderstandings that crop up from different·vocabulary use
• Reducing time and costs in the design and development lifecycle

Please write.