I was asked quite some time ago on Twitter (or perhaps App.net) how I go about putting various apps through the paces. I’ve put together a few tactics over the years to help me with the process. There’s no way I’d be able to handle working with several task managers and other apps at once without setting myself up in advance to do so.
Many of you won’t need to go to the levels I have with this. But if you can take any elements of this approach to decide whether or not an app, service, or product is going to work for you over the long term, then you’ll be better off in terms of efficiency and (more importantly) effectiveness.
The OWN Test
One of the first things I do when I evaluate an app or service is to put it through a gatekeeping process. Initially, I used the acronym NOW to recall that process but I’ve since altered it to OWN (mainly because of The NOW Year).1
Here’s what OWN represents:
- O is for Obvious: I look at an app or service and decide if it is going to be obvious enough to be used. This area is where apps like Day One and Sleep Cycle shine because I clearly know what they are for as they do one thing — and they do that one thing well. But apps like Evernote and Drafts can run into trouble here because if their use cases aren’t obvious (or obvious enough when compared to something else), they’ve got a real uphill battle to stick around.
- W is for Why: The “why” acts as a gut check more than anything else. I’ll ask myself, “Why do I really need this app?” and “Why can’t I use this other app I already have instead?” to ensure that I’ll spend the time necessary to get comfortable with the app or service.
- N is for Need: This is the final litmus test. If I don’t need the app or service, it’s not going to make the cut. That also applies to existing apps when facing new competition. My writing apps have gone through this process a number of times, with apps that are more feature-laden (like Writing Kit) eventually getting cut in favour of another less feature-rich app (like Byword) because other factors come into play.2 This aspect isn’t looked at until I’m done with all other evaluations, which go well beyond just the obvious and the why. There’s more exploring that I do, and that starts with consistent use. That consistent use is monitored with the use of templates and contexts inside, well…an app or service.
Templates
The use of templates can come in handy as well. Templates come in all shapes and sizes, depending on the app or service being used. For example, Asana allows duplication of projects, so when I want to test various components of it I’ll simply duplicate an existing project and muck around with it a bit. Asana allows for use of colours, so I use that feature to indicate what one to play with and what one to work with.
Contexts
I’m a big fan of using as few contexts as possible, and the ones I’ve aligned myself with over the past year have been energy levels (High, Normal, Low), Errands, and Someday/Maybe.
But the ones that come and go are usually named after apps and services that I’m testing.
In order to make sure I am giving apps and services their proper attention, I’ll assign certain tasks and projects to an app. That app will be given its own context (or tag, depending on what task management solution is being used). When I’m looking at my tasks for the day I’ll often use a view that puts contexts/tags front and center, which gives me a visual trigger to — in this case — go to the app in question to work on the task.
If I decide that the app or service is going to make the cut and remain a part of my workflow, I’ll assign the tasks and projects within it my usual contexts and also drop the app as a context/tag. If I decide that the app isn’t going to make the cut, I drop the app and the app as a context/tag — and in some cases I’ll assign the tasks attached to that app to another app (which would also be a context at this point).
Essentially, by using the apps as contexts/tags, they trigger the use of them. Otherwise, they wouldn’t get used enough to be properly evaluated and they certainly wouldn’t be used as part of what would be my actual routines and workflow.
When apps and services have the ability for templates in some form to be used, I’ll use them. But more often than not, I’ll use contexts instead as they are less disruptive to my workflow than working with templates. I know I can always create a context or tag for an app or service; I don’t know if I can create a template. Certainty wins over uncertainty every time in this case, because there’s already so much other uncertainty involved when bringing a new app or service into the fold.
That’s how I test apps. This process allows me to do so quickly and effectively, and while it took some time to build up that speed the effectiveness has been quite high since I started using it because I’ve already built my own achievement structure in advance.
If you’ve already got a solid foundation in place, then use some (or all) of these tactics when testing new apps and services. It might just help you find the apps to make your work and life better and eliminate the ones that won’t…or aren’t.
Photo credit: greshoj via SXC.HU
1 Thanks to Nick Wynja and Michael Schechter for helping me get the order of the acronym right.
2 Byword works on every Apple device I own frictionlessly. Writing Kit, at present, does not.
