Building an app that your co-workers might actually use
Start simply, gather feedback, iterate, and then get your app noticed
The modern day hero comes in many forms, including the delightful co-worker who builds a custom Slack app and makes work life better for many fortunate colleagues.
In this post, we’ll discuss our approach to building an internal app that supported the following two basic workflows on our team:
- request testing support from the quality assurance team
- sign off on a new feature when testing was complete
Our conversations with colleagues indicated that a solution to these two workflows would save time for people requesting support, and it would also enable testers to better prioritize their work and communicate the results of their fine work. We figured that if we were successful, people would actually use this app!
Define success for your app
Even if your app is only used internally at your company, it’s important to think of it as a product and explore the issues your users are facing. So spend a finite amount of time exploring the issues your users are encountering and potentially contemplate these three questions:
- What are their goals?
- What are their pain points?
- How can your app makes things better?
In our case, engineers, designers, and product managers need to make somewhat formal requests to have their various works tested. Unfortunately, the template for making such requests was buried deep in a dusty derelict document. It was hypothesized that our users goal would be to request support in the most helpful way that communicated their needs clearly in the least amount of time so we proceeded with development under this assumption.
At the other end of the testing pipeline, our quality engineers wanted a fast way to post results of testing and share a standard set of information. This sounded like another excellent candidate for automating a workflow with our app.
Make it simple then make it better
“Don’t let perfect get in the way of good.” Yeah, perhaps it’s a cliché, however the point is very valid when it comes to getting your app out into the wild. The simple advice is to make a basic functioning version of your app available to your audience. Don’t spend an inordinate amount of time tweaking the styling of any messages, or creating overly complicated interactive messages, unless absolutely necessary to achieve your app’s stated goal.
With this in mind, we built our app to use two slash commands, one for making requests and one for signing off on requests. The slash commands would open a dialog (which now support up to 10 form elements) with several predefined fields and the app would then post a resulting message in channel.
This basic flow saved time for the person making the request; they didn’t need to think about formatting the message in Slack and then didn’t have to worry about missing a field that the testers were expecting. In both cases, sending a message into channel with a common format made the information easier to read and highlighted critical information like deadlines and channels containing relevant details.
Sample dialog to request testing:
The first iteration of the app posted messages using the old-timey attachment format. You might remember that archaic format from a couple months ago. Once we verified that the app was actually being used, we solicited and incorporated feedback from our users. One such improvement was to implement the app’s message using our recently released Block Kit composition framework. If you haven’t used Block kit, the builder is a great place to start to understand how your app can now compose richer messages.
Sample request message posted to channel:
We started with basic messages, got the app in front of our users, got their feedback and then invested some time on functional and visual improvements knowing (hoping) that our efforts were providing immediate value.
Get your app noticed
Let’s face it: if you build it, they might not come. Therefore, it will be crucial to make noise in just the right places to get the attention of the people who might reap the rewards of your solid work. You’ve designed and built this app to achieve a goal or solve a problem for real humans, so be proud and confident!
Take your app on a channel roadshow
Just as you temporarily shifted your mindset to that of a product manager, it’s now useful to think as a marketer. It won’t matter if you built the greatest app ever if no one knows the slash commands or how to trigger your app to make the magic happen. So find a few public channels in your workspace with your desired userbase and introduce your app. Post an informative message about how to use your app, including a short video of it in action and request feedback… lots of feedback.
Consider variety of entry points to your app
Slash commands are one way to trigger an interaction with apps. Some Slack users love them while others are unsure what the heck they do and wonder what evil gave rise to their peculiar existence. Chances are you might want the widest audience using your beloved app, therefore consider how different types of users might prefer to use or discover your app.
App actions are the modern day slash command in a sense. They have the added benefit of providing message-level context to your app and have a fairly visible place in the Slack client’s user interface. We decided to enable two app actions, “Request QA help” and “QA Sign-off”, that replicated our two slash commands. It might seem redundant, and it is, and that’s kind of the point. The actions provided more access to our app and maximized our footprint amongst slash command friends and foes alike. Furthermore, the code to handle these two types of interactions is fundamentally the same so the cost of development was very minimal.
Show it some love and then yell (respectfully) about it again
By now, you will have planned and built your app, received copious amounts of feedback, implemented new features, and found ways to attract more users. You might be thinking, “I’m done now right?” Well, you could be. But if you want your app to avoid the desolate destiny of a dusty document, you’ll want to treat your app with the occasional love and attention and then remind your colleagues (you’re bound to have some new ones by now) that your app is there to help.
To reignite the fervor surrounding the momentous release of our app (editor’s note: history can be subjective), we added support for link unfurls for URLs related to a testing tool we use internally. While it didn’t have anything to do with our original features, it did fill a gap for some of our users and provided a reason to remind our friends that our app was here to stay. Feel free to think outside the box in this step, be creative and then be proud all over again.
Building apps that actually get used is a reasonable and attainable endeavor. Defining a vision for its success, validating an initial design and trumpeting its existence should aid in your noble quest to help your fellow worker.
Questions or feedback? Email devsupport@slack.com or tweet @SlackAPI.
