UPA Lightning Talk: PAGANism at athenahealth: Pattern Libraries in the Wild
•
0 likes•566 views
PAGANism at athenahealth: Pattern Libraries in the Wild Pattern libraries have been proven helpful at places like Yahoo and eBay in establishing a more consistent user experience but seem at odds with agile development processes. Come learn how one irreverent group called PAGAN at athenahealth is currently trying to bridge the gap and what has worked (or not worked) so far.
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Similar to UPA Lightning Talk: PAGANism at athenahealth: Pattern Libraries in the Wild
Similar to UPA Lightning Talk: PAGANism at athenahealth: Pattern Libraries in the Wild (20)
Recently uploaded
Recently uploaded (20)
UPA Lightning Talk: PAGANism at athenahealth: Pattern Libraries in the Wild
- 1. PAGANism at athenahealth:Pattern Development in the Wild Jannis Brea September 21, 2011
- 2. The Challenge Build a pattern library at athenahealth with little or no resources Revive a languishing group Foster cross-functional acceptance (even within the UX group) for pattern library use 2
- 3. Our Approach: PAGANism. Patterns are proven solutions to a user problem that can be used to solve similar problems in different contexts PAGAN = Patterns and Guidelines in athenaNet PAGAN exists to support R&D by managing the pattern library Encouraging pattern use and development Enforcing pattern adherence Maintaining the library documentation 3
- 6. 6 athenaUXDesign Pattern Library
- 8. 3 Key Lessons so far… 8 1. Don’t be design-centric in a cross-functional program. 2. Give people the tools they will use. 3. Work within the project development cycle.
- 9. Working with Patterns 9 Planning/Design Design/Code QA Are there existing patterns we can use? Leverage the library If existing patterns don’t work, why? Is there a strong reason to modify an existing pattern? Keep an eye on implementation & consistency Let PAGAN know of unmet need How can we better prepare for next cycle? What patterns to create or update? Update the library
- 10. Where We’re Heading… 1. Build up a pattern library 2. Solidify a process for interacting with the library and its curators 3. Build a pattern metrics dashboard for R&D 10
- 11. Concluding Thoughts 11 1. Keep your audience in mind. People, not patterns, are the heart of this effort. 2. Recognize your mistakes and be prepared to redo your work. 3. Don’t invest too heavily in any one process.
- 12. End page
Editor's Notes
- Full disclosure: this is still a “work in progress” – we don’t have fully working solutions to these problems yet.But I thought that there was some valuable insight for this group into the messy process: what things don’t work and how we’re adapting to what we’ve learned as we go along.
- Most people here already are quite familiar with patterns. At athena we define them broadly, as “proven solutions to a user problem that can be used to solve similar problems in different contexts.” Essentially, interaction designs that provide a consistent user experience but are flexible enough to work in a variety of situations in athenaNet.We have a working group called PAGAN to facilitate the development and use of these patterns.Cross-functional team made up of members from UX and Development with key VP-level stakeholders of both groups in regular attendance. Our charter is to help encourage pattern use and development by discussing and approving pattern changes. It also now includes building out the processes around patterns and aspects of enforcement.
- The UX group started at athenahealth in 2007, when the company was already 10 years old. Among its first endeavors was to build a pattern library – one designer was charged with building up a library so he went off and wrote lots of patterns based on web best practices. The patterns themselves, however, looked nothing like what was in the application, nor did they provide incremental steps for how to bring what was there up to this “golden” version.Review meetings, while heated, are philosophical at best. The designs ultimately had little relevance to the application because they were so far removed from the current system, they weren’t practical. They didn’t respect the product or the culture that had built it to this point.Key point 1: Patterns aren’t just about design. At athena, our patterns were just as much the functions living in the code libraries as the designs on wireframes.Key point 2: If you want a cross-functional product, you need cross-functional input.
- Returning to the UX part of this story: the pattern development process had turned to a side-of-desk project that all designers were supposed to work on in project cycle lulls. Tool using was homegrown wiki built for development; Syntax was quirky and templating was difficult had to write and create sections for each pattern from scratch. People who were motivated to create patterns either created workarounds or switched to documenting them in wireframes that lived inconspicuously in a folder on the drive. End result was you could never be sure of what patterns even existed or in what state of review they’d been in.Problem: Low motivation to use home-grown tool and workaround created poorly visible documentation
- Solution part a:) Switch to a different platform. Wordpress instead of Wiki.Switched over to a wordpress site for content management. Solved a few problems: first we could template the pattern documentation process. Lowering the barrier to pattern documentation would, hopefully, get more people to quickly jot something into the library during their “project lull” time.Also enabling comments to allow for dialogue on specific patterns that didn’t require sifting through meeting notes. Built-in functionality like timestamps on comments and revisions would allow us to track a specific pattern’s history.
- Solution part b) Simplify the pattern documentation. Use postcard-style pattern (acknowledge Salesforce team presentation on Agile patterns) Lastly, we also simplified *what* we were documenting in a pattern. We modeled our pattern format after the “postcard pattern” highlighting key sections such as:What user problem does the pattern solve?When to use it?When not to use it? As well as giving designers free reign to document the interaction design. The focus has been predominantly on interaction design over visual design so far.
- Ultimately, though, we had to make using (or not using) the patterns matter – for everyone in the R&D team, but most especially for our PM and Dev partners.Problem statement: Our original plan was to develop the library in a small group, off to the side, then roll it out, but this wasn’t possible as a side of desk project. We had no budgeted resources but still needed to get patterns done.During that time, we did successfully create a few new patterns. In looking back, every single one of them came out of a project execution, so we decided to move more explicitly in that direction.
- Solution: Work with project execution teams to transform outgoing code bit by bit into patterns. Establish a process for using pattern library and getting feedback on changes in a rapid manner via a “council” review system (with communication managed by yours truly). Project teams are asked to look to and use the pattern library for their projects. Project teams looking to break from pattern (our most common case) are required to make their case and either extend pattern functionality or use the pattern as-is. Truly new cases are asked to budget time into making the code into a pattern the first time around.Switched to a leaner “forum” or “council” format of high-level R&D decision-makers who review requests within the context of the product cycle. Luckily, (perhaps unsurprisingly) the same people who form the core of the PAGAN forum also sit on the project review meetings.One full time person (me) tracks pattern usage and update requests, gets the information in front of the decision-makers and gets an answer back to the team within the project timeframes (ideally by the end of their design phase). It’s much faster and more in keeping with the Agile development process we run.
- Build up a robust pattern library that people can use to solve quick design problems. Not meant to remove the need for UX expertise but to teach people in R&D a little more about design and shift conversations to harder interaction problems. Also reduce the amount of time our developers spend coding if our wireframes are referencing patterns for which there are well-documented and tested references.Continue to make using patterns matter – as long as don’t have resources for a separate development and design team to build out the library, we use whatever time we can from existing projects And by collecting metrics along the way we can build up a case for dedicated resources, as well as providing a cool snapshot of R&D output.