Presenters: Daniel Schwartz, Arin Bhowmick; Oracle

Summary of their experience:

• Specific use case design pattern set = domain abstraction
• Valuable for organizations of any size
• Documentation demands _large_ time commitment!
• Need to create balance, when to reference existing patterns vs. build new
• Critical: properly scope what are pattern vs. product features
• Critical: efficient post-design strategy (just as key as optimal design)
• Design pattern success = documenting best practices for domain + being actually implemented org-wide

Definitions

• Design Pattern: Best practices within a design domain
• Design Pattern Set: Grouping of patterns for a design domain
• Use Case Design Pattern Set: Grouping of patterns/sets for a usage domain

Design Pattern Sets vs. Specific Use Case Design Patterns

• Software: Organizing the Content (specific: Application Installation)
• Software: Showing Complex Data (specific: Shopping Cart)
• Software: Getting Around (specific: User Preferences)

User Research:

[1] Methods
• Site Visits
• General Patterns Research
• Stakeholder, Subject Matter Expert (SME) Interviews
• Existing Product Audits
• Usability Studies

[2] General Patterns
• Van Duyne, Douglas K., Landay, James A. and Hong, Jason I. The Design of Sites. (2003)
• Tidwell, Jennifer. Designing Interfaces.
• “Yahoo! Design Pattern Library.” 2006. Online.
• Van Welie, Martijn. “www.welie.com --patterns in Interaction Design” 2006. Online

[3] Stakeholder and SME Interviews, Product Audits
• In the enterprise landscape, majority of SMEs are also product stakeholders and visa versa
• Conducted product audits with SMEs: VPs, Dev Leads, Product Managers
• Significant domain expertise (knowledge and years)
• Successfully able to identify user goals, user issues, common features.
• Identify UI paradigms within existing designs found successful/unsuccessful

[4] Usability Studies
• Reviewed existing usability reports
• Conducted new studies during design phase
• Used an interactive storyboard/ prototype
• Tested with experienced users: internal + customers
• Validated new interaction concepts
• Proved very valuable in making critical decisions about new concepts.
• Findings were integrated into final design

[5] Wish List
• Review of existing external research papers & case studies into the domain
• Conduct more in-depth targeted user interviews & observation (w/ site visits) after meeting with stakeholders
• More usability studies across different user types
• Usability activities conducted earlier in design phase

Design

[1] Methods

User Modeling
• More difficult to narrow down for more generic patterns.  Example: Sortable Table (Also mentioned by Tidwell)
• As with specific products, critical for a specific use case design pattern set.
• In the enterprise space, well-established user profiles just need refinement (esp. for mature products)

Iterative Design Process focused on:
• Identifying best solution workflow patterns
• Iterating on storyboard design feedback from stakeholders & peers.
• Effective documentation/communication of pattern set

[2] Pattern Documentation

Uptaking VS. Referencing Existing Design Patterns, Pattern Sets
• For new design pattern set, do we reference existing design patterns or create new? Example: For an app installer design pattern set, need a unique installer wizard pattern?
• Tried both approaches, but uptaking existing patterns better met needs.

Creating new:
- Pros: Most control over design; Concepts & visual examples can be specific to pattern -> reducing pattern learning curve for consumers; Can include unique features for the domain
- Cons: Design process time increases as need to write own patterns; If leverage pattern changes, need to go in and see if specific use case pattern needs to uptake those changes.

Using Existing:
- Pros: Speeds design process; Less writing maintenance
- Cons: Less control over design; As patterns get updated, aspects may not apply; Concepts/visuals too generic for pattern consumers -> significant learning curve

[3] Pattern Feature Scoping

Pattern Features VS. Product Features

• For specific design pattern set, what belongs in a pattern set versus what is a feature left for product teams to implement individually? Example: An approval mechanism for app installers that may vary per app.
• Patterns should primarily focus on covering common functionality (majority use cases)
• In enterprise space, need to balance design resources; cannot provide full design support for every feature
• For features not used by a majority of apps, found need to provide guidelines on how to expose those features

Documentation

[1] Effective Design Communication

• Visual and interactive communication methods proved most effective
“A picture is worth a thousand words. An interface is worth a thousand pictures.” -Ben Shneiderman, 2003

[2] Common Terminology Set: Define & use consistently

• In enterprise space, large and varied groups may have different vocabularies to communicate concepts
• Identified need during user requirements gathering phase when speaking with different product teams/ stakeholders
• Communication greatly facilitated by all parties
• Examples:
 - Login vs. Sign On vs. Connect to
 - Submit vs. Finish vs. Install
 - Remove vs. Purge vs. Delete
 - Save vs. Commit
• Proved useful when communicating with centralized working team of specific use case design pattern set

Post-Design Support Strategy

[1] Keep a Centralized Working Team

• At enterprise level, large number of products to support for uptake of a common product
• Promote uniformity at the UX (design patterns) and development levels.
• Development and UX representatives from different app product families (HR, Manufacturing, etc…) to facilitate a top-down uptake.
• Representatives regularly updated on latest design & development changes.

[2] Support the Use Case Design Pattern Set

• Tutorials: training, recorded training demos, office hours, templates for rapid prototyping
• Communication/ Collaboration Tools: email distribution list, discussion board support group (bulletin board, wiki, etc..)
• FAQ list
• Formal design pattern exception process
• Integration into bug filing system.
• Allow users to file bugs against design patterns for usability issues and feature requests.

Links

• UX at Oracle: http://ui.oracle.com
• Fusion apps: http://www.oracle.com/apps/fusion.html