Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
<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.