Design Questions

[amorey]

Design System

1. Are you using a UI library or building from scratch? Shadcn?

We are building up our own UI library in a project called kubetail-ui that consists of a Tailwind plugin to establish a common set of color and style defaults, and some basic components (e.g. button, dropdown). Currently the library consists of components pulled in from a few libraries including shadcn but as time goes on we want to switch to shadcn wherever possible.

Project Goals and Requirements 

1. What are the project goals? Scope?

The goal of the project is to identify some basic usability improvements to the Kubetail dashboard's home page and logging console (e.g. colors, typography, spacing) and in the process learn about Kubetail users and the product as a whole.

2. Timeline?

1-2 weeks to identify usability improvements then another 1-2 weeks of answering engineer questions at implementation time.

3. We are establishing a design system?

Long term we want a complete design system but for the purpose of this project we should only establish a minimial design system that will get us a few usability wins in the short term. Ideally this minimal design system will be the basis for a more complete system in the future.

4. Are we designing for light and dark mode?

Yes, we are designing for both light and dark mode. In fact, most developers seem to prefer dark mode but this is annecdotal.

5. Are we designing only for desktop?

Yes, we are exclusively designing for the desktop. Although we may want to design for mobile in the future, currently we are only focused on desktop.

Collaboration w/ developer

1. What should the dev/designer collaboration workflow look like?

While a project is in the design phase, most collaboration will take place casually in Discord, Figma or GitHub Discussions. Interested developers should feel free to poke around designs and ask questions, and designers should feel free to pull in developers to ask them for their opinions. Also both designers and developers are encouraged to ask our users (many of whom are in our Discord) for their opinions.

When a design is ready for implementation, we will prepare a "Technical Spec" using the template in GitHub Discussions. The spec will contain a description of the change being proposed and any mockups, if appropriate. The process of writing the spec is an opportunity to bring everyone together on the design and implementation side and hash out most of project details at a technical level. Once the spec is ready, we will turn it into an a GitHub Issue where it will be picked up for implementation. Depending on the complexity of the project, the implementer might have some follow-up questions and we might need to revisit some aspect of the design or the technical spec.

Outside of specific projects, there are always small design questions that come up and both devs and designers are encouraged to talk to each other and ask for help in Discord, with a preference for communication over open channels so as many people can stay in the loop as possible.

2. How are we prioritizing which issues to tackle on first?

At the moment, intuition. We use the product ourselves so intuition can take us pretty far but in the future we would like to conduct more formal user interviews to identify priorities.

Collaboration w/ designer

1. Establishing working and collaboration norms?

We have a "Contributor Resources" page on our GitHub org homepage: https://github.com/kubetail-org/ where we have been putting all of our contributor-related documents. We should identify any missing documents or other ways to establish working and collaboration norms. One thing to keep in mind is that every contributor is a volunteer so we have to be cognizant of their other obligations.

Problem Space

1. Who are the users? Developers using Kubernetes?

Our users are

1. Individual developers who are developing applications in a Kubernetes development environment
2. Cluster administrators doing basic monitoring of production clusters
3. Devop engineers identifying problems and bottlenecks in production clusters
4. App owners doing monitoring and triage on applications running in production

2. What challenges/paint points is Kubetail solving for users?

At the moment, Kubetail makes it really easy for users to view the logs for multi-container workloads. A workload in Kubernetes consists of many instances of the same application (running inside a "container", grouped together as a "pod") running in a cluster of servers ("nodes"). Individual instances of the application come into and out of existence so following the logs for an entire workload can be cumbersome. Kubetail makes this easy by letting the user view logs at the level of the workload instead of the individual instances of the applications.

3. What does success look like for the user?

When the user is performing monitoring, success means they feel confidence that the apps in their cluster are running smoothly without problems. When the user is performing debugging, success means they were able to identify the problem quickly or at the very least were able to identify the time slice where the problem occurred quickly and download the logs for deeper analysis.

4. Where does Kubetail fit in a developers journey? (I want to understand the user journey)

Since the only dependency for Kubetail is Kubernetes itself, a user can start using Kubetail inside their development environment to view the logs for their local cluster. With Kubetail running on the desktop, you can easily switch between clusters so a user can then switch between their local cluster and a remote cluster by using the cluster picker in the UI. By default Kubetail only obtains cluster data from the Kubernetes API which is very limited. If a user wants more advanced functionality such as log file sizes, last even timestamps and remote search/grep they can install the "Kubetail API" to upgrade their experience.

5. Who are Kubetails’s competitors? Datadog? Newrelic?

There are many companies and projects building observability tools including Datadog, Newrelic, Grafana, Victoria Metrics, Honeycomb, Mezmo and SigNoz. Currently, the most popular tools all require users to use a hosted or self-managed service to store/host/serve their logs and metrics. The approach we're taking is to be extremely light-weight and zero-cost so users can extract as much value from their clusters as possible without spending any extra money or much compute resources.

6. What screens do we currently have?

Currently we only have a "Dashboard" product with a home page for displaying workloads and a logging console for displaying logs themselves. When the dashboard is run in auth-mode: token there's also a login page where a user can input a token.

[designgirl001]

Really nice questions, it provides a lot of context around the ways of working.

1. Could you share a diagram(technical diagram) of an application that we may all know of - say e-commerce or social media and help us visualise the microservices architecture? I'm confused between clusters, containers, nodes and pods. How do these parts fit into each other? I think this is helpful to understand where the data comes from, what data comes in, and the dependencies.

2. Is this an observability application primarily? The core value prop then will be about how best to present the data and help facilitate quick decision making.

3. Has there been any user feedback around the UI/UX thus far? Visuals, accessibility, application flows, pending user needs etc?

4. What might really also help is if you could share (or talking to a user would help) understand a day in the life of a developer - and what motivations they have to use Kubetail. This will help us understand some driving goals to optimise the design.

[amorey]

1. Could you share a diagram(technical diagram) of an application that we may all know of - say e-commerce or social media and help us visualise the microservices architecture?

Here's a high-level diagram of a Kubernetes cluster running six "nodes" spread across three "availability zones" (US-EAST-1A, US-EAST-1B, US-EAST-1C) in an AWS region (US-EAST-1):

Each node is an AWS server instance running Kubernetes-related software necessary for the machines to coordinate with each other. In addition, the nodes are also tasked with running "pods" which you can think of as individual instances of an application (e.g. a web server, a thumbnail generator, a database). Kubernetes moves the pods around the cluster depending on the load on each machine so at any point in time different nodes can be running a different number and different types of pods. We can talk more about containers later but for now you can just think of containers and pods as being the same.

2. Is this an observability application primarily?

Yes but "observability" is the umbrella term for the space and currently, Kubetail is only focused on logs which is a subset of observability so I prefer to describe it as a "logging tool" or something similarly focused. In any case, the core value prop is how best to present the data and facilitate quick decision making.

3. Has there been any user feedback around the UI/UX thus far?

We've gotten very positive user feedback but it's all been part of casual conversations. We haven't done any formal user interviews.

4. What might really also help is if you could share (or talking to a user would help) understand a day in the life of a developer - and what motivations they have to use Kubetail

Sounds great! I think the best way to do this is to actually start doing user interviews.

[designgirl001]

Thanks for this! And of course, this leads to more questions haha. It's still not very clear though I think this could be resolved over a call and a product walkthrough.

Do you have any notes/documentation from the informal chats that have been done so far?

[amorey]

Sure! Happy to do a call and a product walkthrough. In terms of notes, we only have comments users have left like this:
https://github.com/orgs/kubetail-org/discussions/318