I've worked on Cloud Bigtable since before the General Availability launch about 3 years go and led UX of this feature from inception to completion.
I worked closely with another designer using pair design methodology.
Throughout this projects, I also worked closely with over a dozen cross-functional partners, including product managers, back end and front end engineers, UX designers, researchers and writers, tech writers, and program managers, as well as leadership.
Erica, a data engineer, wants a replicated system that can isolate batch jobs from a cluster serving live data.
Jay, a data admin, needs their data to always be available, even if a zone goes down. They run daily analytics on past data, so it's not critical if data is a little bit behind.
Alex, SRE, is responsible for making sure that the system is running smoothly and needs to be able to redirect traffic if it’s not.
Allow users to replicate their data to another zone within the region for additional read throughput, higher durability, and resilience in the face of zonal failures
Reduce the burden on support through richer monitoring of Bigtable instance status and health
Make this new (and extraordinarily complex) functionality understandable to new and existing Cloud Bigtable developers, specifically, supporting a clearer mental model for routing Bigtable requests
Analysed and summarized foundation research and make it actionable
Conducted 4 design sprint cycles of iteration, with usability testing and cross-functional feedback integration throughout
Produced final mocks, red lines, and accessibility annotations as well as a deck of more forward-looking designs
Evangelized good UX process and product excellence through deep involvement in launch process
Mentored a more junior designer
Some bonus responsibilities
Delivered a presentation on Bigtable UX considerations for eng management
Led participant recruiting at HBaseCon to increase customer engagement and facilitate future usability testing
Created an internal Cloud Bigtable explainer to help provide context for internal decision-makers and help with onboarding
Designed some team swag :)
We developed the concept to help users understand, manage, and control requests in a multi-cluster setup.
Data is automatic replicated between clusters, regardless of app profile configurations.
All requests go to a single cluster
REPLICATION: SINGLE CLUSTER ROUTING
Requests can be routed to a specific cluster to enable read-write consistency.
REPLICATION: MULTI-CLUSTER ROUTING
Requests can be routed to any cluster, allowing for seamless failover if one cluster becomes unavailable.
This feature is critical for adoption and increased usage by many new and existing customers.
Metrics can't be shared for confidentiality reasons.
“Cloud Bigtable replication helps us simplify replication setup where we don't have to do the dirty work ourselves. Most importantly, it saves us development time and gives us peace of mind that our data is safely and correctly replicated.”
— Aleksandar Aleksandrov, Data Engineer, MessageBird