We’re trying new ideas for our startup and they need to be tested quickly. With real users. We’re just connecting available dots without reinventing the wheel if there’s existing solution for particular problem. Here’s an example what we just did in a few days.
Our flagship Frank is well accepted by customers. They like it, because it’s simple (survey with five questions) and it gives them good results. When compared to another performance review tools (like 360, etc.), it’s blazingly fast. But how many surveys are you going to create per year? Three, four? Probably. We’re still thinking how to improve the whole evaluation process and here comes another idea – Angie – it’s all about results and fair evaluation. Fair means that team members are going to evaluate each other, not biased manager. This evaluation is processed more often and is based on events. Event can be anything in this context. For example – daily meetings, releases, business deals, … Simply whatever. Every team can decide how often they would like to evaluate each other. Every team member can create an event. Team members gain / lose reputation points based on actions like create event, up vote, down vote, … Team leader (or all members) can decide what they’re going to do with these results – it can be part of your salary, one-time rewards, etc. This tool is also inspired by the Stack Overflow reputation system. Let’s write some prototype.
First thing we need are users and teams. The easiest way is to reuse existing information. Don’t forget, we’re just prototyping. Lot of companies use Slack today. Slack has quite nice API and interaction components like dialogs, interactive messages with buttons, … What about teams? Team in the Slack context is the whole organization. But there’re channels and these channels are mainly used to divide people into groups with some specific topic. Angie can treat channels as teams for now.
Nice, first task done – we have users and teams. What’s important is that no one needs to register, create organization, maintain members, organisation chart, … It’s really important for prototyping. Not just for you (developer), but also for your prototype users / testers. Keep it as simple as possible.
Event is an entity with name and list of participants (= team members = Slack’s channel members). Slack provides dialogs. They’re kinda limited (text field, text area or options), but they suit our needs and we are going to use them. How one can open a dialog? Slash command. In our case, it’s
/angie new [event-name] [#channel]. Here’s the result.
Whenever user hits Create button, application receives payload with validated user input. We can validate it again (if it’s required, Slack provides simple validation like input length only), send back errors (shown in the dialog itself) or just accept it for processing.
Notification to users
We can think of ephemeral messages sent to respective users in the selected channel. It’s not a good idea.
Ephemeral message delivery is not guaranteed — the user must be currently active in Slack and a member of the specified channel. By nature, ephemeral messages do not persist across reloads, desktop and mobile apps, or sessions.
I already did this mistake, because I missed this paragraph in the documentation and these messages are not delivered if user is not active (offline, …). We stick with im.list, im.open and chat.postMessage to the IM (direct message) channel. These messages are always delivered.
Any message can contain attachments with buttons. Let’s reuse them. Here’s the example of the voting message.
Buttons can have style like default (black), danger (red). Whenever user hits the button, application receives payload with callback id and other values we did provide. Application can just accept the payload or return modified message. We’re returning modified message reflecting current status:
- black button – user didn’t vote for this member,
- red button – user did vote for this member.
Voting solved as well. We know it doesn’t scale for massive amount of users (message cluttered with lot of buttons), but we also do not target huge teams, so, it’s enough. Again, just prototyping.
Another commands (like
/angie top, …) were introduced as well. These commands allow anyone to check current events statuses, …
/angie list example:
/angie me example:
These textual reports are nice, but it’s not what our users expect. Charts are simply a must and we do not want to do develop them as well. Here comes the plot.ly service. We can prepare charts in the Jupyter Notebook and reuse the same code in our application with plotly package. Just replace
plotly.offline (notebook) with
plotly.plotly (application). It also allows us to upload secret charts and share them with anyone (private link with auth key). Or we can just embed them anywhere with the same link.
/angie report and
/angie evolution introduced. Plot.ly is little bit slow (takes up to 10s to generate the link), so, both of them are asynchronous. User will receive link when they’re ready.
Report leverages Sankey with all the events on the left side and members on the right side.
Evolution is a simple day to day distribution of reputation points in your team.
And now we have charts for just $400 / year. Yes, we have to pay to get secret charts with private links. But it’s still very small amount compared to other solutions like developer’s salary working with D3, …
Prototype is finished and we’re gathering data. Later we have to analyse them, modify reputation points distribution (change gain / lose points per action). And if we will be happy, we’re going to improve it and create MVP from it.
Glad we have so many services around these days, lot of them are for free and they do allow us to rapidly prototype. This one was finished in several days (~ 2 weeks). Not bad for something users can directly test.
If you’d like to test it, feel free to add it to your workspace. But remember, it’s a prototype.
Other technologies used
That’s it for now. Don’t reinvent the wheel and reuse everything you can find for your prototypes, MVPs, …