The Iterative Process: Designing a Scheduling Component for Extra
As a young designer, I attempted to overcome the terror of a blank document through brute force. However painful it was, and however long it took, I’d sit at my desk and try to make things work—no knowledge of grids, of vertical rhythm, of typographic hierarchy or ratio, of precedent or pattern. This worked for a while: I learned how to make beautiful things. But it was emotionally gruelling. I remember a compulsive desire to show my work to others in embarrassing bids for affirmation (which was mostly withheld, thank god). And I remember feeling desperate to be let into the process of other designers. Did they have half-baked ideas? How did they deal with them when they did? I was eighteen and these were the types of questions that I asked.
Since then I have learned that designing is more about what isn’t on the page than what is—that the hard work begins and ends before a designer even opens a Sketch document. But in the interests of helping my younger self, I wanted to start sharing more of my process. To that end, here are two versions of Extra—my first attempt, and how it looks today:
There are a few dozen iterations between these two compositions, and it took three or four weeks of work to feel comfortable not only with the visual design but with how it all fit together. My younger self would have been horrified to learn that things take time, that there’s often a process around making things good (preferring, I think, more romantic ideas of divine inspiration and natural talent—gack!). In an effort to demystify that process a little bit, let’s walk through a tiny part of the above—designing the interface that controls Extra’s post scheduling.
When we have an idea for a feature or a product, Matthew (my cofounder) and I spend a good deal of time discussing its implementation. Once we’ve come to a general understanding of a feature’s functionality, I’ll typically jump into Sketch, create something rough and start to iterate on it. While early iterations are often new concepts, later iterations are just small tweaks. Here’s a screenshot of the many different iterations that I did trying to nail the scheduling logic:
What was I doing during that process? Let’s step into it.
First, some background: Extra is a tool that allows you to automatically repost evergreen content to your social media feeds. To represent this in the UI, we settled on three entities around which most user actions are performed: channels (social accounts), schedules and collections (collections of posts). Each channel has a unique schedule, and schedules themselves have time slots. Each time slot is associated with a collection. We wanted to be able to have unique schedules for different days, so we decided that time slots should have different recurrence types (all weekends, week days etc.). Got it?
My first attempt at a scheduling interface was a small area at the top of each collection that allowed you to modify time slots for each type of day (weekends and weekdays). Users would be able to tell us when they wanted to tweet, post or pin something from one of their collections from the collection itself. It looked like this:
There’s a few problems here. Not only does this solution limit the number of time slots a user can have by using a dropdown (a decision that we made too hastily), it doesn’t allow for unique schedules on individual days. Moreover, locating schedules within collections isn’t particularly smart, considering it’s probably more important for users to have granular control over the behaviour of each social media account (more important than having granular control over when a collection posts). Here’s what I came up with next:
Okay, so, things are getting a little bit more complicated. I’ve solved the issue of limiting time slots, moved the whole scheduling logic from Collections to Channels, and added some more interface to provide more control over what gets posted when. But again this isn’t working. The layout looks broken now that there are multiple time slots (and what happens when a user modifies a time slot? Do the items reshuffle?). It was time to try something else. Take a look:
Here I’ve created a more visual layout that could theoretically accommodate more time slots. Pretty cool right? Adding a new time slot to the type of day would drop another data point on the timeline, and you’d be able to drag the times around, or modify them manually. Problem solved!
Nope. It’s too damn complicated. Am I designer or a monkey? At this point, I could tell that I wasn’t thinking high-level enough. There was just too many moving parts and too much interface. I took a shower, and fretted about my career. That’s when the following solution hit me:
In the above, each day has its own tab. Toggling between days of the week is easy and is the highest-level action. Within those tabs, time slots can be created and destroyed (not edited, because of the problem of reshuffling), and they can be freely associated with recurrence types and collections. Bang. The masterstroke. There was still some work to do to minimize jerkiness in state changes and to visually clarify certain item’s associations. Here’s what I ended up with:
What do you think? Hit me up on Twitter.
Update: Some Excellent Feedback
Clint Schnee (of UXPerts): “Does a time slot need to be constrained to a single collection And, use of colour to augment collection names would be a nice touch (Trello style).”
Andrew Austin (of Crew): “(1) Would the user ever need or want to see a full-week overview for a channel? Presumably they could look at Monday and see that they have Everyday items scheduled, but I’d imagine in planning out their schedules, they might like to see a simplified overview to aid their task. (Also, moving the schedule to the channel was a good call.) (2) I might not be fully understanding the parameters, but if the user can’t edit a time slot (only create and destroy), I’d only show the Recurrence and Collection dropdowns when adding a new time slot”