Cut the time to run commands in Slack, Teams, Discord by 30%-50%
"I think this is really cool feature because it saves time."
Ivan Dobrinov
CTO, 1crew
"This a cool feature, it will make debugging easier, especially when debugging on Slack Mobile. It can be a pain to type the commands."
Dino D'Ambrosio
Senior DevOps Engineer, Sensor Networks
My role: Only Product Designer on the team
Responsibilities: User research, Requirement generation, Low and High fidelity prototyping, Close collaboration with Engineering
Overview: Design of an innovative CLI replacement for chat applications.
The why and influencing the roadmap
The first thing I did when I joined the Botkube team was to identity the main points of friction within the product on all levels and stages. How do people learn about the product? Is the installation experience seamless? What's their first interaction with the product like? How about their experience after that?
One of the common complaints was that it is more difficult to type commands in a chat app like Slack than in a terminal app because there is no auto-complete or history.
There were many design constraints introduced by Slack's or Teams' APIs and design components.
I had to design around Slack API-specific constraints like drop-down menu max width or the inability to disable any UI component, and generally a very limited set of UI components.
Making chat alerts actionable to reduce context switching
The main thing that Botkube does is to alert users about issues with their apps and infrastructure via chat messages on Slack, Teams, Discord and Mattermost.
One issue, however was that the alerts were not actionable. The end-to-end design was sort of broken as we told the user there's a problem but no easy way to act on it or investigate further.
The solution was to attach a simple drop-down menu with relevant, contextual actions according to each alert. The available actions also depend on the cluster permissions and we had to be very careful not to allow destructive actions (like kubectl delete) to be executed without proper warnings and precautions.
Addressing user feedback
Some of the user feedback we got is that once a command is typed, the output is difficult to deal with - one has to copy/paste or even switch to a terminal app.
In the above case I asked myself why should the user have to copy / paste or even type commands in the first place? This wasn't exactly the problem that the user explicitly described but by sharing their story I could decipher that along with the specific issue they wanted fixed (log formatting).
The technical stuff
The engineering team helped me understand and learn about Kubernetes' kubectl and helm utilities which allow users to manage their Kubernetes clusters and applications.
The utilities have roughly the following syntax:
kubectl [command] [TYPE] [NAME] [flags]
helm [command] [RELEASE] [CHART] [flags]
The actual utility command, a sub-command and then the thing that the sub-command is applied to (a Kubernetes resource). Name and flags are optional but important. Some examples:
kubectl get pods -n namespace
kubectl describe pods podname -n namespace
helm upgrade postgresql-1668168192 bitnami/postgresql postgresql-1668168192u
Feedback-based iteration and what did not work
Initially the goal was to make the bot's output interactive as that would have addressed the user feedback immediately. You received a list of pods? No need to copy/paste the name of the pod if we present the list as radio buttons or a drop-down. Need run a kubectl command on that pod? Simply select a command from a drop-down.
A kubectl command and its output
Explorations on how to parse command output and make it interactive in Slack:
Eventually however this approach did not work. It felt a bit overwhelming and unusual to users that they had to first select a Kubernetes resource (an object), we had a hard time properly labelling and categorising the objects and that approach didn't work very well on small mobile screens.
Output filtering
(like UNIX's grep but for Slack)
Often times debugging infrastructure and apps involves using commands that generate long output - hundreds, even thousands of lines. Parsing such output is a more or less solved problem on sophisticated systems, but not on Slack.
The design we went for is conceptually based on the UNIX grep command where one can filter command output by one or more string patterns. This way of parsing is familiar to our users and matches their mental model. For simplicity sake we allow filtering only by one string pattern at a time, though I have developed prototypes that allow for more patterns.
Full demo
Before
Users would have to type each command and its options flags without autocomplete and other terminal features.
After
Users need only type 'k' at the bot to trigger a fully interactive experience that would 'build' the commands for them.
This website is a work in progress. Some sections are incomplete or unavailable, no mobile and large screen support yet.