<Insert Picture Here>

CxP Design Sprint Maria Fernandez Trevino

Agenda

• Intro to Agile • The design sprint • Unified design board • Daily schedule options

Design Sprint

• Product Owner: Tim • Scrum Master: Maria • Development (Design) Team: Matt, Benson,

Maria, Nathan, Ritchard, Mary Beth, Teddy, Dave • Stake Holders: DLS, Thyaga, Marc, Mark, Igor,

Vlad, Daniel, Kamal, Ken, Soraya • Sprint Length: 3 weeks

Design Sprint

• A designer is both in the sprint and looking ahead at what comes next.

• The UI designer’s top priority must be to the work of the current sprint. If a team member needs a clarification on a design for a product backlog item being worked on in the current sprint, the designer stops thinking about next sprint and answers the question about the work of the current sprint.

• The UX board should show the stories assigned to UX that sprint, as well as the stories containing UX that Developers are working on during that sprint, so we can estimate sprint capacity accurately.

Com

ponent Boards

CXP UI/UX

Board

Web Client Board

Desktop Sync Board

iOS Board

Site Builder Board

Capture Board

N+1 Jira Board

SCS PM Board

Gemini PM

Board

Unified D

esign Board

Unified D

esign Board

• Tons of boards (per component), this is fine and necessary actually, but as long as we have one unified UX Board we should be ok.

• Anyone (PM or DEV) should be able to add a task or story to the UX backlog by adding the UI/UX component and the UX designer if known (else assign to component lead).

• If a story is PM or Dev driven, details or a spec should be available for the story. • UX can also add stories to our backlog to track UX specific roadmap items and UX specific

projects (usability, research, etc) • UX driven stories need to be defined by UX, so a spec/details needs to be added by us

before it can be marked as done. • A story will typically have at least a UX task, but many times will also have a Visual task,

and a UA task as well.. • When UX is done, UX can mark the UX task as done and assign to Visual or UA so they can

complete the task if applicable. • Once a story has both the UX and the UI tasks complete, then UX can put the story in the

DEV backlog (by changing component and component lead) • A complete story will include

• Visual task is done • UX task is done • The main story contains enough info in the details section describing the feature, and when

needed, a link to the conversation where the spec was uploaded for discussion and finalized.

• The product owner (Tim) will triage, prioritize and assign stories (both PM and UX driven) into a sprint, being mindful of the other stories DEV is working on in the active sprint.

• The UX designer is the POC to any UX/UI tasks associated with a story. They need to triage any changes and needs. Developers should not directly contact UI designers.

• The UX designer is responsible for reviewing and approving the Acceptance Criteria written by dev. This always happens during the sprint.

• The UX designer is responsible for supporting DEV, PM, QA during implementation.

• We should have our grooming meeting after DEV has groomed their boards.

• We need to attend DEV standups (daily) and we should have weekly ones among ourselves.

• We need our own: • Planning/grooming meetings • Sprint Review meetings (UX specific) • Retrospective meetings

Unified Design Board

Schedule Option 1

MON TUE WED THU FRI MON TUE WED THU FRI MON TUE WED THU FRI Dev sprint planning (only your platform)

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Sprint Review Dev Desktop

-Review acceptance criteria for all stories in the active sprint -Author specs and designs for PM driven stories -Define UX driven stories, their detail, design, specs, etc. -Support dev with any blockers or impediments for the stories in the active sprint -Attend PM meetings where they review upcoming feature work concepts

UX Weekly Stand-up

-Review acceptance criteria for all stories in the active sprint -Author specs and designs for PM driven stories -Define UX driven stories, their detail, design, specs, etc. -Support dev with any blockers or impediments for the stories in the active sprint -Attend PM meetings where they review upcoming feature work concepts

UX Weekly Stand-up

-Review acceptance criteria for all stories in the active sprint -Author specs and designs for PM driven stories -Define UX driven stories, their detail, design, specs, etc. -Support dev with any blockers or impediments for the stories in the active sprint -Attend PM meetings where they review upcoming feature work concepts

Sprint Review Dev Mobile

UX sprint planning (1hr per 1 week sprint)

Sprint Review Dev Web

Sprint Review Sites

Sprint Review UX

UX Retrospective

3 Week Sprint D

aily Schedule

Schedule Option 2

MON TUE WED THU FRI MON TUE WED THU FRI MON TUE WED THU FRI Dev sprint planning (only your platform)

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

UX sprint planning (1hr per 1 week sprint) -UX Team

Design Day -Author specs and designs for PM driven stories -Define UX driven stories, their detail, design, specs, etc.

Design Review -Every one in the UX team + relevant PM/DEV stakeholders

Design Day -Author specs and designs for PM driven stories -Define UX driven stories, their detail, design, specs, etc.

Design Delivery -Every one in the UX team + relevant PM/DEV stakeholders

Dev stand-up

Dev stand-up

Dev stand-up

Dev stand-up

Sprint Review Dev Desktop

UX Weekly Stand-up

-Review acceptance criteria for all stories in the active sprint -Support dev with any blockers or impediments for the stories in the active sprint -Attend PM meetings where they review upcoming feature work concepts

UX Weekly Stand-up

-Review acceptance criteria for all stories in the active sprint -Support dev with any blockers or impediments for the stories in the active sprint -Attend PM meetings where they review upcoming feature work concepts

Sprint Review Dev Mobile

Sprint Review Dev Web

Sprint Review Sites

Sprint Review UX

UX Retrospective

3 Week Sprint w

ith Design Spike

Daily Schedule

<Insert Picture Here>

Oracle Documents UX UX Process Maria Fernandez Trevino

Agenda • Intro to Oracle Documents Project • UX Process

Oracle Documents Cloud aka Athena

• File sharing and collaboration that • Creates end user delight by

simplifying the way users work with content – online, offline, on any device

• Facilitates file sharing and collaboration with users inside and outside the organization

• Addresses IT concerns of management, content security and compliance

• Target use cases • Secure extranet file sharing • Team file sharing and

collaboration • Cross-device file synchronization

Athena Competitive Landscape

• Infrastructure players (Amazon, Google, Microsoft) are providing free basic document storage services for consumers

• Dropbox and Box claim 80+% penetration of Fortune 500 companies. Provides evidence that users/departments are subscribing to the services

• Dropbox has focused on personal use. Dropbox now starting to promote team use. Box has focused on department and SMB file sharing . Box now targeting enterprise sales

• Personal/consumer space is a race to the bottom. Athena should focus on the department and enterprise market

Consumer file backup

ECM On Demand

Cross-device file

synchronization

File sharing File collaboration

?

Oracle Documents Cloud aka Athena • Purchases of cloud-based document services in large organizations are still driven

by departments. Key drivers are: • Fit for purpose solutions e.g. virtual data rooms, project collaboration, cross-device

document availability with minimal customization requirements • Extranet collaboration – access to documents outside of VPN, collaboration with external

users, multi-organization collaboration

• Cloud services have been adopted by end users (individually and for teams) in the majority of Fortune 500 companies but there are very few enterprise wide deployments

• Opportunity for Oracle: • Provide a service designed to address the most common cloud file sharing use cases.

Design to win a competitive end-user evaluation for the target use cases • Identify areas to provide differentiated functionality e.g. synchronization, sharing, desktop,

tablet app • Target enterprise sales by providing user and file management tools, security controls,

compliance support and APIs/UIs to integrate Athena with other applications and services

Athena Web UI • To design and deliver an elegant, fast, intelligent user interface for

managing and interacting with content in a collaborative environment • Rich capabilities for sharing, collaborating, and securing content that

encourage quick adoption and viral expansion • Tools for detailed activity monitoring and careful management of users,

groups, tasks, and content access • Simple but powerful integration technologies to:

• Surface Athena capabilities to other OPC products and external applications

• Consume other OPC and external capabilities • Adaptive Design to intelligently adjust to desktop or tablet form factors for

maximum user delight • Designed for the cloud

• jQuery library and widgets, JSON, backbone, CSS/SASS, etc. • Architecture scales to provide terminal velocity user experience • Nimble technologies facilitate efficient development and agile delivery

• Leverages Oracle Cloud Content Server for repository and business logic

The UX Process

• The UX process the team has established will ensure we give adequate attention to each feature area.

• The process is pretty straight forward and it officially starts after PM releases the Mini-Spec or PRD for each feature area.

• It is meant help us provide a great, coherent, and cohesive user experience in Athena and to keep the wider team informed, on the same page and on track.

The Process

UX Spec Review

Visual Design

*Usability Evaluation

UX Research +

Design Phase

UX Walkthrough

*Usability Evaluation

*based on availability

UX Research + Design Phase Audience

• Required: UX team

Goals

• Understand business problem, user needs, and scenarios • Competitive landscape: review applicable design patterns and competition • Define UX goals • Create high-level wireframes • Create storyboard for primary scenario

Deliverables Deck containing:

• Business Problem • Feature Research • UX Goals • Storyboard

The Walkthrough (Conf Call)

Audience • Required: The dev, the tester, the PM, the usability engineer, and the

technical writer assigned to the feature. • Other UX designers and PMs working on the product. The wider

audience.

Goals • Get everyone familiar with and in agreement with the business problem

we are trying to solve and the main UX goals for the feature. • Illustrate with mock-ups a detailed core scenario. • Gather enough feedback to modify the goals and the proposed UI if

needed be.

Deliverables • Feedback for future iterations and/or approval/sign off for feature area.

Usability Evaluation

Audience • Required: The dev, the tester, the PM, the usability engineer, and the

technical writer assigned to the feature. • Other UX designers and PMs working on the product. The wider

audience.

Goals • Evaluate the most important features early on. • Near the end of the release, evaluate the product as a whole.

Deliverables • Usability report including usability test results and recommendations for

future iterations.

UX Authors Detailed Spec Goals • Identify and define detailed feature behavior. • Work-through edge cases.

Deliverables Document containing:

• Business Problem • Feature Research • UX Goals • UX Requirements • Details of all elements and interactions

The Spec Review (OSN)

Audience • Required: The dev, the tester, the PM, the usability engineer, and the

technical writer assigned to the feature. • Other UX designers and PMs working on the product. The wider

audience. Goals • Identify relevant issues, lacking sections, potential problems. • The finalized UX spec is the main document dev and test agree to base

their work on.

Deliverables • List of spec updates/additions and/or approval/sign off of spec by all

disciplines.

Visual Design Audience • Required: The dev, the tester, the PM, the usability engineer, and the

technical writer assigned to the feature. • Other UX designers and PMs working on the product. The wider

audience. Goals • To incorporate Visual design as early as possible in the process for

finished feature areas. • We may use placeholders for pending visuals and artwork.

Deliverables • Visual specs and visual artifacts or placeholders to finalize feature

implementation.

UX Iterations (OSN, Conf Call as needed)

Audience • Required: The dev, the tester, the PM, the usability engineer,

and the technical writer assigned to the feature. • Other UX designers and PMs working on the product. The wider

audience. Goals • Resolve any open issues. Deliverables • Update the UX spec with illustrations and/or descriptions of new

behavior and/or issue resolution

Addendum 1) UX posts UX Mini Spec or Deck to an OSN conversation illustrating the interaction for a certain single

feature or closely related feature area. Feedback window is opened until a certain day. 2) When feedback window closes, UX uploads updated spec with the pending updates, PM to sign off. 3) After sign off by PM, UX uploads finalized UX Mini Spec or Deck to spaces folder above: Web Center

Product Team Folder for UX and Visual Specs. The specs go in the corresponding iteration subfolder. If the spec is not finalized, they can go into subfolder Proposed, if Final, then they go into subfolder Final.

4) Visual design uses same OSN conversation to upload the matching visual spec repeating steps 1-3. If

the visual spec doesn't line up with the UX spec, then it gets it's own independent conversation. 5) If there are visual design artifacts like icons or art work, these resources go into the spaces

folder: Web Center Product Team Folder for Visual Design Artifacts. 6) OSN Conversation is closed after the UX and/or Visual specs have been marked as final and

uploaded to the Spaces folder. If new revisions to a finalized design are needed, these are to be discussed in a new OSN conversation.