Tracking time is hard, but necessary
Teams are often required to track their hours for billing, payroll, or simply because the organization wants to measure time spent on certain initiatives. Let’s face it, time tracking is not everyone’s favorite task. This means that a solution built for tracking time needs to be both easy to use and be where the user is.
And this is exactly what our vision for our time tracking solution has always been. We strive to make time tracking as painless as possible. Part of making time tracking super easy is by ensuring that it is done in a timely manner.
We know that time tracking is more accurate and meaningful when the time is recorded shortly after it is done, or even in real-time.
This means users should be able to record their hours with the least amount of mouse-clicks or keystrokes. It’s even better if they are reminded to do so when communicating with their team about these tasks.
We thought: It’s all about encouraging people to form a habit of tracking their hours.
[callout class="user"]Here’s a great podcast about behavioural change, if you’d like to learn more.[/callout]
Our journey to build an application with Slack began when we transitioned to Slack as our internal chat tool at Tempo. This sparked the idea that we should be able to use our own time tracking solution with a tool that’s become an integral part of everyone's work day.
What if you could record your work hours directly from your chat?
With this question in mind, we set out to create a Slack integration, which aims to merge conversation and time management in a single platform.
In this blog, we'll explain some of the UX challenges we overcame when building our Tempo for Slack app, and we'll dive into our solutions for those challenges.
Mixing GUI elements and typical chat flows
There has been a lot of buzz around conversational UI and bots. However, there are drawbacks to interacting with bots using text only. By supporting GUI (graphical user interface) elements inside the conversation, Slack enables third party vendors, such as ourselves, to use the right UI given the specific scenario.
Mixing GUI elements with a typical chat flow poses an interaction challenge, however. When a user interacts with the bot, the developer has the choice whether each interaction is a part of the chat flow, or if each interaction is shown only when needed and subsequently replaced by the next step in the flow.
We decided to go with a thoughtful mix of both.
The Tempo bot uses a more traditional chat flow when it’s beneficial to the user to be able to see earlier steps. Alternatively, the bot replaces some steps with the next ones when it may be confusing for the user to see and be able to respond multiple times to contextual questions.
For example, when a user logs work from our bot, the workflow includes both direct text interactions with the bot as well as being able to use buttons and the new Slack message menus.
As you can see above, it makes sense to directly speak to the bot to tell it what you’ve been working on and how much time you’ve spent. It’s much more user friendly to simply click on a button of options to begin the flow. The message menus allow our customers to easily navigate through recently viewed JIRA issues.
Associating Tempo users with the relevant Slack user
In order to solve this problem, we experimented with a few different options:
- Requiring that a Tempo administrator links Slack users to JIRA users in order for our bot to know which Slack users and JIRA users go together. This option could be cumbersome, but it also provides the admin with some control over who is linked and who is not.
- Requiring that each user authenticates Slack themself (allowing us to link their Slack id with Tempo user id). The upside to this option is that the administrator does not have to do this for each user and it provides an onboarding opportunity with the user. The drawback, however, is that this depends on the user doing it themselves.
- Performing the linking of users between Slack and Tempo automatically, for example, by comparing data from both systems (i.e via e-mail).
We decided to go with the 2nd option in which a user must authenticate the Tempo for Slack app themselves. This means that the first thing a user needs to do is enter the URL of their JIRA instance to get the app up and running.
This solution was the best option for us to start with, because the admin does not have to link users. In addition to that, team members using Slack and Tempo can simply choose on their own whether or not they’d like to use the app. It also does not bring up the same security concerns as with the 3rd option.
[callout class="user"]While developing the app, the team found bot kit to be easy to use and the community very supportive. We highly recommend checking it out if you’re thinking of building a Slack bot.[/callout]
Reconciling our brand and voice with a new UI
As a third party integrating with another platform, it can be a challenge for us to maintain our branding and voice, while still seamlessly integrating with the host platform. The way we approach this issue is by adopting the UI style of the platform in which we’re integrating. We ensure, however, that we use the appropriate opportunities to express our product, voice, and brand.
Adapting to a new UI
One small, but important example of how we adopt the style of the host platform is through buttons. Currently we use them on a few different platforms:
- Our website
- Our add-ons for JIRA
- Our Slack app
Although we have our own brand style, we choose to use the button format of the platform in which we’re integrating with. This includes how that platform formats words on the button as well as the look and feel.
[callout class="tip"]As we were developing the Slack bot, it came almost as second nature to use the same sentence case (only capitalizing the first word) that we use for our JIRA add-ons. It was only after developing our beta when we had a chat with our designers and realized that we should use title case (capitalizing all words on the button), so that our buttons match the look and feel of Slack.[/callout]
Staying true to our brand
It’s important for us to incorporate our own brand as well. We do want to be recognized, after all. Since our Slack bot interacts with the user in a private chat, one obvious way to do this was to set the avatar for the Tempo bot as our logo. We wanted to take it a little further, however, and decided to incorporate our own color scheme for the attachment messages.
Another important aspect of branding and UI design, which is often overlooked, is the tone of voice and writing style we use. As with the visual aspects, we want our language to fit with the platform and interface we’re developing for, while still being true to Tempo.
Since this is the first time we’ve built an integration with a conversational UI, we needed to define how that voice should sound. It took a few iterations and collaboration between our developers, UX writer, and marketing to find the perfect wording for the bot itself, the process of adding the integration to Slack, as well as the help center and marketing materials.
Let’s take the example of writing for the bot itself. We needed to consider the bot’s point of view, so we asked ourselves questions such as:
- Does the bot speak in the first person?
- Does the bot speak as a separate entity or as the Tempo platform as a whole?
- What kind of personality does the bot have?
We chose to see the Tempo bot as similar to a hotel concierge. A concierge represents a hotel and helps guests with what they need to do. He rarely refers to himself; his vocabulary is more focused on the hotel, the guest, and providing a good service. The Tempo for Slack bot similarly represents the entire Tempo platform through its conversation, while still remaining a single entity.
As integrators, any challenge during the development process becomes more complex. The solution, however large or small, must take into account the needs of our own customers, as well as the users of the platform for which we build. It must also reconcile the visual and contextual branding and UI of that platform as well as our own.
When two become one, it’s hard not to lose something in the process. Therefore, we constantly ask ourselves: How seamlessly can we integrate, while remaining authentic?