Institutionalizing UX in IT : Evolving from Skunkworks to User-Driven — What Took You so Long?
Happy Monday and February
The Boss threw down a challenge last week. He asked our team to put together a preso for brass outlining what should be our vision for Institutionalizing UX in Enterprise Services. He asked for a 1, 3 and 5 year plan. Someone has had a wake-up call and now IT wants to know how we are going to help our organization go from a focus of building lots of functions to meeting user needs — and how does that play with the Agile method we have adapted? Sheesh.
Of course, the first thing we did was to go to Neilsen’s treatise on the stages of usability maturing. The gist of his writing: to truly become a user-centered organization, companies almost always progress through the same sequence of steps, gradually increasing their levels of commitment to usability.
Stage 1: Hostility Toward Usability
Stage 2: Developer-Centered Usability
Stage 3: Skunkworks Usability
Stage 4: Dedicated Usability Budget
Stage 5: Managed Usability
Stage 6: Systematic Usability Process
Stage 7: Integrated User-Centered Design
Stage 8: User-Driven Corporation
According to JN, it takes about twenty years to move from stage 2 to 7 and another twenty years to reach the last stage.
Links:
Right now, I am trying to figure out what stage we are in. I am going to say off the top of my head that we are in Stage 3. However, if we can actually get UX story points added to our projects, we might look like we are in stage 4.
We are in various stages depending on what project you are talking about. I think we are definitely in Skunkworks UX . We still have a whole bunch of Stage 1 and Stage 2 thought and practice going on……
Some other things that I came across in my mad Googling: HFI User Experience (UX) Maturity Survey. HFI developed this survey to capture a comparative view of the maturity of usability operations around the world. http://www.humanfactors.com/UXMaturitySurvey.asp
The good news is that HFI’s UX Maturity Survey 2009 seems to indicate that usability has transformed from a business differentiator to a routine component of business practice — at least in the companies surveyed. According to the blurb on HFI’s site: “Stable, visible, internal usability and user experience groups with executive support have become significantly more prevalent since Eric Schaffer outlined the elements of a mature usability/user experience practice in his book, Institutionalization of Usability, A Step-by-Step Guide (2004).” (I admit that I haven’t read this book – I just received it. Thank you Amazon.com)
Also came across some articles that I have bookmarked as interesting from my new fave UX resource site: UXMatters
Gabriel-Petit, Pabini. “Sharing Ownership of UX.” UXmatters, May 28, 2007.
—— “Specialists Versus Generalists: A False Dichotomy?” UXmatters, February 9, 2009.
Jones, Colleen. “When ROI Isn’t Enough: Making Persuasive Cases for User-Centered Design.” UXmatters, May 7, 2007.
Nieters, Jim, and Garett Dworman. “Comparing UXD Business Models.” UXmatters, July 10, 2007.
Sherman, Paul J. “Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent.” UXmatters, January 20, 2007.
As we are figuring out what we want our take away to be when we present, we’ve come up with these bullets which are now attached to my cube on post-its:
- Focus on the user and all else will follow (see Google)
- Our company is HERE on the scale of UX Maturity and we want to be THERE
- This is going to require both a cultural shift and a tactical shift
What took you so long??
Indeed.
UX Libraries and Agile Application Development
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.
- 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
- Document anomalies to those patterns and make recommendations for improving consistency
- 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.
