Making things flow
As fast as you type, writing code (that works as intended, of course) takes time. Even for a small scope like TaskFight, it’s a good idea to spend a bit of time ahead of coding scribbling which screens are necessary and what they’ll contain. Faster to change a sketch on paper than code.
Which screens do I need?
The journey of someone using TaskFight looks like this:
- Enter the tasks in the app
- Compare, compare, compare
- Ta-da! See the rankings.
This maps perfectly to 3 screens:
- The task list screen, letting people input tasks and see the tasks he had entered already.
- The comparison screen, where users would compare the tasks two by two until all have been compared.
- The results screen, displaying the results to users.
Boom! All sorted! What happens after the person got their rankings, though. Some time later, maybe they’ll have another list of tasks they’d want to sort out. They need a way to start from scratch. Would they think about hitting refresh to get started again? or would they expect it to just reload the results page? For lack of more user testing, I made a guess and chose to add a button to the app to start anew.
People will make mistakes too. Maybe they’ll mistype one of their tasks. Or they’ll start comparing and realise they forgot to input a task. I needed the first screen to have a way to delete unnecessary/incorrect entries. And I also needed to add a navigation to go back and forth between the screens.
The screens content
What each screen needed to display was now clear. I could then look into how things would appear on the screen. For now the focus is just on where everything goes and in what size.
Screens come in different sizes, though: small ones like smartphones, bigger ones like TVs. And different orientation & ratios too. Someone might use the app on its 16:10 monitor, but another user might be holding its 4:3 tablet in a portrait position. Something to keep in mind when designing where things go, as the layout will need to adapt to all these situations.
General layout
Some elements are common to all screens. It’ll be easier for users if they are in the same position on each screen. So I started by deciding on a general screen layout.
Most of the space should remain dedicated to the specific screen features. But I could take some of it to put a header and footer to hold the common features. Even in landscape screens, with limited vertical space, this should leave enough space in the middle, so I won’t make any adjustments.
Navigation will only come after having used the main screen, so it makes sense putting it at the botton. Not to mention it makes it easier to access on a touch device. The branding and reset button can then go in the header at the top.
Time to decide on the specific of each screen.
The task list
First off, the task list. Looking at its features it’ll need some kind of form where users can type in their tasks. Nothing fancy, an input field and a button will do. It’ll also need the list of tasks they have entered already, so they can double check what’s already there.
What if they input something they’ve already added? Best prevent that so they don’t end up doing the comparison for a given task twice. That means I’ll need to add some validation of the form input, as well as an “error” message when people enter duplicates.
The list doesn’t have anything special besides the need to remove entries in case of mistakes. Displaying a “remove” button for each entry will clutter the screen quickly. So I decided to hide them by default and to reveal them on demand. When browsing with a mouse, they’ll reveal on hover. Otherwise, they’ll appear when tapping the entry.
It makes the feature not visible at first glance, but hopefully, the interaction is simple enough to keep things usable. If it doesn’t work, I can fix this in the next iteration anyway.
The last part was deciding how things should be arranged on the screen. I went for simply stacking the form above the list. It’ll be the first thing the user need after all. A quick thought for when the screen is on landscape position. Shall the list become horizontal? That felt a bit weird. Break into columns? Not ideal on narrow screens. So I kept things in one central column, like for portrait screens.
Comparison screen
The second screen is where users compare the tasks. Display two tasks, pick one by tapping on it. For this the bigger area there is to tap the easier to use. That’s why I went for splitting the screens, with each half being the area where users can tap.
How the screen is split would depend on the orientation of the screen. One entry above the other for portrait works well. But for landscape, it’ll be better one next to the other.
The results screen
Last is the result screen. “Just” a list of the entries, in the order they end up after being compared. That didn’t mean there was nothing I could do to help users a bit. Making sure the list is numbered, for example, so they can figure out how far from the top priority they are when scrolling down.
Speaking of their top priority, obviously it’ll be the task at the top. But I can emphasize it’s the top item by making it bigger, so it appears visually more important than the others.
In the end, black and white boxes were not the look I wanted TaskFight to have, though. It was time to play a bit with colours and shapes and create the branding for the app.
Thanks for reading
Hope you enjoyed it. The journey is now over and the app will soon be released. You can subscribe to the newsletter to get notified when it'll get opened :)