Designing Cloud Products
•Download as PPTX, PDF•
1 like•320 views
Speaker: Eliane Kabkab, Senior Product Designer, MongoDB Track: WTC Lounge Working on the product design of MongoDB Cloud requires an interesting marriage of technical and design process knowledge. This talk will walk you through the stages of designing for Cloud Manager, Ops Manager and Atlas. Drawing examples from the Cloud “Organizations” project (or the redefinition of our Cloud “groups”), we will discuss the identification of existing customer patterns and pain points, and how they lead into a set of concepts and solutions. We will also address validation, prioritization and the back and forth process that results in the development and release of our Cloud features.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Designing Cloud Products
Similar to Designing Cloud Products (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
Designing Cloud Products
- 1. #MDBW17 A Use Case Walkthrough of Designing for Cloud DESIGNING CLOUD PRODUCTS
- 2. #MDBW17 Senior Product Designer, Cloud Services ELIANE KABKAB @elianek
- 3. #MDBW17 WHAT IS PRODUCT DESIGN? “The efficient and effective generation and development of ideas through a process that leads to new products” - Morris, R. (2009). The fundamentals of product design.
- 4. #MDBW17 A CASE STUDY: “ORGS AND PROJECTS” A redefinition of our Cloud “Groups”.
- 5. #MDBW17 LET’S START WITH THE PROBLEM • “Groups” are confusing • Customers are getting big and they organize in silos ‒ Central administrators ‒ Separate organizations with their own cost centers and employees ‒ Several MongoDB deployments with unique requirements within organizations • Management of large deployments is not easy ‒ Top 20% of our customers have an estimated 50+ nodes deployed ‒ Some have more than 1000
- 6. #MDBW17 … AND THE NEED Enable large enterprise administrators to more easily manage their company’s set of MongoDB deployments.
- 7. #MDBW17 AN IDEAL PRODUCT DESIGN WORKFLOW • User Research • Requirements • Create Wireframes and Flows • Create Prototypes • Collect Feedback and Validate • Support Engineering • Product Ships! • Look at Metrics
- 8. #MDBW17 AN IDEAL PRODUCT DESIGN WORKFLOW • User Research ‒ Paves the way for all future phases
- 10. #MDBW17 RESEARCH GOALS “Descriptive” – getting exposed to users, and asking the best questions to: • Understand the problem context • Refine the problem statement • Get “inspiration” for a solution that fits most
- 11. #MDBW17 MAKING A RESEARCH PLAN • Goals • Questions to be answered • Method • Participants/audience • Schedule
- 12. #MDBW17 RESEARCH PLAN: GOALS • Explore most common use cases • Dig deeper into users’ current problems and needs • Narrow down audience for better solution
- 13. #MDBW17 RESEARCH PLAN: QUESTIONS/HYPOTHESES • Exploring use cases: ‒ Making of deployments in the organization ‒ How are they organized across groups ‒ Making of users ‒ Migration across groups ‒ Deployment management ‒ Administration of shared settings (shared across multiple groups/projects)
- 14. #MDBW17 RESEARCH PLAN: QUESTIONS/HYPOTHESES (CONTINUED) • Org Structure: ‒ How are teams organized? ‒ What are the security permissions? • Pain points: ‒ What issues do users run into in the current model? • Billing ‒ What level is it managed on?
- 15. #MDBW17 RESEARCH PLAN: METHODOLOGY • Interviews! ‒ 5 internal, 6 external participants. ‒ Internal: o Align goals o Gather what our company already knows about users o Learn about gaps in our knowledge ‒ External (our users and MongoDB customers): o In person at participants’ offices and remote over phone or video o Fill in the gaps in our knowledge
- 16. #MDBW17 RESEARCH PLAN: SCHEDULING • Internal interviews from: ‒ Product Management ‒ Consulting (larger Ops Manager customers) ‒ Solutions Architects • External interviews: ‒ Intros from internal employees ‒ Meetings with DBAs, platform teams and developers
- 18. #MDBW17 USER INTERVIEWS: DRAFTING SCRIPTS • Non leading, open-ended questions • Example: ‒ How big is your team? ‒ What is your role? ‒ What did you do yesterday? ‒ What are you trying to achieve? Why? ‒ Can you show me how you currently do it? ‒ What can be improved?
- 19. #MDBW17 USER INTERVIEWS: DRAFTING SCRIPTS
- 20. #MDBW17 RESULTS AND OBSERVATIONS • Use cases identified • Pain points • Recommendations
- 21. #MDBW17 RESULTS: USE CASES IDENTIFIED • 4 major: ‒ Continuous maintenance of Ops/Cloud Manager ‒ Creating and setting up new groups for applications needing MongoDB o + ensuring group AND cluster level settings are met ‒ Updates to existing Ops/Cloud Manager groups o Permissions, alerts, and upgrades across groups ‒ Management of organizational data: o Moving data across groups o Backing up, restoring across clusters and groups
- 23. #MDBW17 RESULTS: PAIN POINTS • No holistic view of all clusters/groups and environment types • Spinning up new groups is tedious (repeated settings) • Upgrading across many groups is tedious • Users/roles management doesn’t exist on cluster level
- 24. #MDBW17 RESULTS: RECOMMENDATIONS • “Groups” dashboard • Organization level settings or templates • Ability to restore from one group to another • Permissions granted to groups or clusters based on environment type (production, QA)
- 25. #MDBW17 THE SOLUTION • Groups become Projects • Organizations hold Projects ‒ Billing lives on the Organization level ‒ Organizations have Users, Teams and Alerts ‒ Users and Teams get assigned to Projects ‒ Projects and Clusters get Tags
- 27. #MDBW17 LET’S GO BACK TO OUR DESIGN WORKFLOW • User Research • Requirements • Create Wireframes and Flows • Create Prototypes • Collect Feedback and Validate • Support Engineering • Product Ships! • Look at Metrics
- 31. #MDBW17 EXAMPLE: NAVIGATION UPDATES - Features, including new org layer, didn’t fit quite well in our existing navigation - Quick and dirty mockups to explore options - Presented the team with options and tested them out
- 34. #MDBW17 PROTOTYPING AND USER TESTING - inVision for interactive prototypes - User testing (another whole round of research!)
- 36. #MDBW17 EXAMPLE: MVP AND RELEASE PLANNING - What’s the MVP that we can release? - How can we best phase out the changes to make for coherent releases?
- 38. #MDBW17 REQUIREMENT SHIFTS - Continuous updates to wireframes to account for requirement shifts (to this day!)
- 40. #MDBW17 CURRENT STATE AND FUTURE WORK - Phase 1 not yet released! - Designs for phase 1 finalized, working on finalizing details like copy - Coordinating copy writing with the documentation team, product management and marketing - Refining designs ongoing for future phases
- 41. #MDBW17 GOING BACK TO THE BEGINNING “The efficient and effective generation and development of ideas through a process that leads to new products” - Morris, R. (2009). The fundamentals of product design.
- 42. #MDBW17 HOW WAS IT AS “EFFICIENT” AND “EFFECTIVE” AS POSSIBLE? - Prior research - Internal requirements - User testing - Phases and continuous back and forth - No waterfall
- 43. Questions? Help us do research! Come say hi and sign up to be a participant. Or email: eliane@mongodb.com
Editor's Notes
- Real quick, start by defining what product design is. We will talk about the steps that guarantee an efficient and effective process, and how they apply to technological products, and specifically a very engineering centric product like MongoDB and the cloud. Emphasis on “efficient”, “effective” and “process”.
- Introduce the project we are using in our case study without talking too much about the solution.
- It’s harder for projects to go “ideally” in the real world, and for a project as complex as the one we were taking on, touching every single aspect or feature of our products, this took a lot of back and forth. We will keep coming back to this process as we go, with a focus on user research.
- Descriptive as opposed to exploratory in which the research aims to explore and find the problem. In our case we knew what the problem was.
- Questions: different from the scripted questions we ask users in an interview, these are the hypotheses or questions we are trying to find information about.
- Use cases: in our situation, how are people organizing their environments and users We will explore hypotheses for every one of these
- Security permissions: who has access to what
- Interviews, whether remote or in person at the offices of the participants, allowed us to dig deep into the information we wanted to gather
- Done with the plan! Does anyone know of an example of a non leading question vs a leading question? What are you trying to achieve derive use cases
- maintenance: Looking at all groups/cluster in the org, monitoring their helath, checking key metrics Creating and setting up new groups Group settings (alerts, users/roles, backups etc) Cluster settings: auth/ssl, data paths, startup parameters…
- We did not address all of these, but laid the foundation in our new model to be able to slowly incorporate these features into our product
- Team: Group of users that can be assigned to projects. Teams can have their own permissions. Tags: An arbitrary label for Projects, and potentially Clusters, used for view filtering and permission linking.
- Let’s quickly browse through the rest