<Insert Picture Here> CxP Design Sprint

Transcription

1 <Insert Picture Here> CxP Design Sprint Maria Fernandez Trevino

2 Agenda Intro to Agile The design sprint Unified design board Daily schedule options

3

4

5

6

7

8 Product Owner: Tim Scrum Master: Maria elopment (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

9 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 elopers are working on during that sprint, so we can estimate sprint capacity accurately. Design Sprint

10 Gemini PM Board SCS PM Board CXP UI/UX Board Web Client Board Desktop Sync Board ios Board Site Builder Board Capture Board N+1 Jira Board Component Boards

11 Unified Design Board

12 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 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. Unified Design Board

13 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. elopers 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

14 Schedule Option 1

15 MON TUE WED THU FRI MON TUE WED THU FRI MON TUE WED THU FRI sprint planning (only your platform) UX sprint planning (1hr per 1 week sprint) -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 Desktop Sprint Review Mobile Sprint Review Web Sprint Review Sites Sprint Review UX UX Retrospe ctive 3 Week Sprint Daily Schedule

16 Schedule Option 2

17

18 MON TUE WED THU FRI MON TUE WED THU FRI MON TUE WED THU FRI sprint planning (only your platform) 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 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 stakehol ders 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 stakehol ders 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 Desktop Sprint Review Mobile Sprint Review Web Sprint Review Sites Sprint Review UX UX Retrospe ctive 3 Week Sprint with Design Spike Daily Schedule

19 <Insert Picture Here> Oracle Documents UX UX Process Maria Fernandez Trevino

20 Agenda Intro to Oracle Documents Project UX Process

21 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

22 Athena Competitive Landscape? Consumer file backup Cross-device file synchronization File sharing File collaboration ECM On Demand 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

23 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

24 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

25 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.

26 The Process *Usability Evaluation UX Spec Review UX Walkthrough Visual Design UX Research + Design Phase *Usability Evaluation *based on availability

27 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

28 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.

29 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.

30 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

31 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.

32 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.

33 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

34 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.