This app is focused on answering three big fat ugly questions "when do I work?", "what am I working on?", and "how can I change my schedule?" In small businesses, these issues can cause discomfort at best and frustration at worst. In large companies that employ thousands of people, mistakes and confusion in scheduling can lead millions of dollars of waste. Currently, the process to make changes to an individuals schedule is all manual. Running late to work? You have to manually update that. Want to request additional hours? Manual process for the employee and manager. Someone called in sick? Good luck trying to find a replacement in time.
To top that off, many of the current apps that companies do give to their employees only solve part of the problem. They give visibility into a schedule, but no way to make a quick change on their own. Employees have to call, text, email, or somehow get in touch with their managers and coworkers to make small changes to their schedule. Nothing is automatic, and managers have to play the traffic cop, getting requests, looking into their schedule, denying/approving those requests, and then manually updating the schedules of everyone involved. It's really a mess, and not an easy one to fix.
Now, this app doesn't solve the automation part by itself. There's too many variables to take into account for that to work well in a mobile app. The business writes rules in Intradiem's Rules Engine in order to approve, deny, forward on to management, or whatever they want to do. The mobile app's job is to send and receive that information so that employees can know the odds of their request being approved, and make the right call accordingly.
This app has to replace the piece of paper on the break room wall. Employees need to be able to open their phone, see what they're doing today, tomorrow, or next week, so that they can plan accordingly.
User Initiated Requests
Businesses need to be able to define requests that their agents can make, and what information they'd need to approve/deny/take action on it. These requests need to be available in the app so that users can fill in the right details so that the rules engine can take the correct action.
Odds of Success
This is a harder thing than you'd expect. Both from a technological and intuitive standpoint. This app needed to not only be able to know the odds that a request would be approved, but also need to tell the user those odds, so that they don't go requesting anything and everything without knowing what was reasonable and what was not.
Easy to Use
My frame of mind for this project was that it needed to be better and quicker than a call or text message. If the UI was confusing, no matter the business buy-in, the users would fall back to their familiar methods of doing things. The second there is a hiccup, bug, issue, or glitch, users will forget it exists and worst of all, not trust that it does things as they want it to.
Also, there's an issue of context. People could be using this when their lives are in crisis mode. Sick children, car trouble, family crises could be very present and looming when the submit a request in this app. If this interface is confusing or slow, it could add to the stress of the situation and at worst, could contribute to someone losing their job. We can't have that.
I'll admit it, when chatbots first started coming on the scene, I was smitten. The prospect of being able to give an interface that was familiar and simple to a user was super appealing to me. I knew that the current method of making changes was via text, so I figured, why not just make this a big chat interface? It'll be easy, I said, what could go wrong?
My early hypotheses about creating a chatbot-style interface were promising, but would have resulted in a series of unknown use cases and technological hurdles. I slowly started to realize this as time wore on, but in the end, a blunt question from a co-worker led me to connect the dots and put an end to his misery.
So I killed him.
Otto would live on in our hearts, but not in the app. He'd maybe make a cameo here or there, but this wouldn't be a chat app with a bot. This would be an app focused around making requests that were easier to develop, needed less controls over their creation, and could be changed with little impact on the overall experience. It would have less whimsy, sure, but it would work better for large scale implementations.
While the chat interface had to go, the simplicity of the requests that users could make didn't get the boot. I focused on making a place for businesses to create a list of requests that users could make, fitting different business needs, which in turn would interact with Intradiem's rules engine. Think of it like the IFTTT 'Do' app, but with no user created recipes.
At this point, the schedule is bare bones, the requests are simple, but the important part was the API integrations. We began developing this basic version so that we could do the back end work, and make sure that we would be able to handle the app once it became more complex. At this point we didn't have a diverse set of business cases, so we wanted to prompt conversations with out customers about how they could potentially use it.
The market is ripe for this app with these features, and after some discussion with a large bank, we found some more defined use cases, as well as the demand for a more fleshed out calendar and calendar controls.
The first versions were fairly rudimentary. Mostly they were focused on the calendar interaction.
Then I started focusing on how users would edit their schedules and accept offers of work
I drew inspiration from other calendar apps, but realized that the freedom that those controls would give would be too complex for the types of rules that we'd want our customers to write. Overlapping segments would cause trouble. I hard to restrict the ability for the users to make drastic changes or cause errors to occur.
Now I was getting to the point where it was difficult to communicate the odds of success. I tried color, size, dials, scales, percentages, and nothing really stuck all that well. At this stage I began doing some guerrilla usability testing at a nearby Starbucks and mall. Some people were understanding the concepts, but not very reliably. Also, I started to run into the limits of my prototypes at this point and was getting some bad test results simply because my prototypes were buggy.
So I took a leap in a different direction. I was sitting at home one night, and saw a tweet by Uber of one of their new features or something, I don't really remember. What I saw, however, was how they had solved a problem that I was experiencing.
My prototypes up to this point had been based on a drag-the-dot interface, very similar to Apple's calendar. There's nothing wrong with this interaction in a free-form calendar whatsoever; You can make things longer or shorter with relative ease, and make quick changes without going to a time picker or new screen. But, in my situation, I didn't want to allow users to make changes to their segments that would intersect other segments.
The solution that Uber inspired was to fix the location of the thing being manipulated. and make the rest of the screen draggable. If you make the pin and the map move, then you'd have to constantly worry if your primary action would be moved out of view. Fixing it's location, and allowing everything else to move was perfect for me. Not only did it simplify the logic of the interface, but it also solve a problem I was having with hands blocking the touch targets. I had a few users with long nails (don't ask me how they use phones at all...) and large fingers, who completely missed key parts of the control. With a fixed control, I'd not have to worry about their interaction blocking the important information.
Immediately after making this key change, I started to see users understanding the chance of success, and actually making a different request than the one my scenario had told them to, so that it would have a "higher chance of being approved". Their words, not mine. That was awesome to hear.
However, I now ran into a new issue. Half of my testers tapped on the large black box expecting it to do something, and half starting scrolling the background as intended. I tried creating some new controls to fix the issue, and even added a loading animation and a hint that told the users that they had to scroll, but neither of those fixed the issue. People missed the hint, or tried to scroll it directly.
I almost told my PM that it was fine to develop. I had comprehension of the chance of success, I had a good calendar design, and I had intuitive editing controls in place. it was 75% of the way there, and I figured that with some good onboarding, we'd get everyone educated. I'd spent enough time on this control, and didn't think that there was a good solution.
Then I found it. My issue had been that I had tried to emulate Uber too much. They put their primary action on the button, yes. But doing so led their app to a next logical progression in hailing a car, my button contained the request action. I didn't wan an errant tap to send a request, so the button didn't allow the user to control the time, but it was too much information in too tight of the space. Again I found inspiration in another app, Apple Maps. Their bottom sheet menu gave me the idea to separate out all of the controls and information of the request out into a separate section of the UI. Distancing the time from the request button would make sure that they looked related, but not that they were the same thing.
With this control I didn't run into any of the performance issues in my user test and I was able to get much more credible feedback. It also removed a lot of the complex logic that would have gone into the development of this feature and led to better user test results. After 3 or 4 sessions of good feedback, I chose to lock down the design and then focused on making this control work for our Android application. The following is a video showing the two versions side by side so that you can see the feature parity.