I made a redicuralsy simple timer app.

I made it since I had wanted the app like this for a long. It’s free, search for “ListTimer” on the App Store.

Download ListTimer Here.

※The language of the video is Japanese, but the app supports English too.

This is the simplest app I have ever made, but I created it because I personally want to use it.

Why did I make an another timer app?

I use the default iOS timer app very often, almost everyday. For example, I use it for setting my work time.

In this case, it’s ok to set 3 or 4 hours one time a day. However, if I want to set 3 or 5 minute timer quickly when I cook or do something, it’s a pain.

First, the tapping area on iOS timer app is very small, and you need to select your desired time carefully using that hard-to-use drum roll UI.

I have many situations in which I want to set a timer, but to keep using the iOS default timer app makes me tired everyday, and I wanted to fix it.

How about other timer apps available on the Store?

OK, I tried lots of timer apps available on the App Store myself first. I thought I could find the one suits me easily.

I was wrong, I could find nice apps which have lots of features, or looks cool, and are customizable in different ways. But, All I wanted was a simple app where I can set times very easily and keep using in the long run.

I needed a timer app focused on the part of setting times and starting it quick.

So, I researched on timer apps available, and how I can improve it to make the one I love to use very often.

In the end, I found the easiest way to set times is setting the time list from 1 min to 90 min from the first, and scroll it to start one of them with one-tap.

Every list height should be big enough to tap it comfortable, cool, this suits me best! This is great, simple is best, less is more! I don’t need the other features!

I showed it to my friend, and he said “You can’t set 1:30?”, but I answered calmly just like a king, “This app doesn’t need that, that is because I don’t need it”.

Honestly, I thought I might need to make it possible to customize times, but I can think about it later if this app becomes popular enough.

Background behavior

One problem, third-party apps cannot play audio like iOS default timer app does. This is the same for all third-party timer apps.

I enable Silent mode almost always so this is the most important part for me. If you disable Silent mode, it plays audio with notifications in the background though.

Therefore, this app sends several local notifications in a row to let you know the timer is done.

Local notifications vibrate your device even in the silent mode and background status.

By the way, it doesn’t consume battery power since it schedules a timer locally. It also works offline.

About App Store Descriptions

I like to try new things as much as possible for learning. This time, I have done a different approach on the App Store. Instead of writing the app description normal way, I wrote why I made this app over there.

It could be less boring rather than listing features one by one, oh, wait, this app doesn’t have enough features to list anyway.

I was worried about being rejected from the Apple reviewing process as claiming it as a too simple app, but maybe the reviewer read the descriptions and understood the concept.

Please try it out if you are interested in using the fast one-tap timer app.

Download ListTimer on the App Store here.

*I make an Text to Speech app, one-tap timer and more. About Me.

It’s often said that you should listen to your users to improve your product. However, the reality is, it’s a really tough challenge, and I believe you need lots of practice and experience to do it well.

I still find it difficult to say NO to users, but I want to share my thoughts about this.

I feel bad about saying No to user requests

When I was watching the iPhone5s Apple video, Jonathan Ive said something like this.

We are as proud of the things we have said No to as the things we have done.

I believe this is really important thing for product design.

When your users request or suggest some ideas, usually, every one of them makes sense in their contexts, and I can understand why they want that in most cases.

However, if I execute every great idea, eventually, the product becomes messy one with lots of noises. It ends up being a product nobody wants by trying to make something everybody wants.

We should choose what to execute very carefully.

Having said that, even though I know the principle in my brain, when I get requests from users, it’s still hard to say No to them. Users like your product, and took their precious time to write something to you, but you have to say NO most of the times.

This is not easy.

When I read the 37 signals book “getting real”, I remember they say “It’s hard to say No, but you have to be good at it”.

As a Japanese person, we have a stereotype image about Americans that they are good at saying No. But, even if they think that is hard, for Japanese people who are really bad at it, it must be really tough challenge.

So, what can I do.

How do you reply?

So, how can I say No to users.

To people who took their time to give me feedbacks and requests, how can I reply? I always find it really hard.

For example, one person say like “I need this feature because..”, and you know that is useful, but you want to protect simplicity of your product.

Let’s say you explained like, “I understand the value of the feature, but I cannot make it since I need to add features which will be used for 80% of users at least.”

In this case, for users who requested the feature, it doesn’t matter if they are in the 80 % category or not, I might end up pissing them off by explaining to them with data.

I really want to say “I will do it in the near future!”, but making a promise about future plan is the last thing you want to do in product development.

You never know how your product goes, and you cannot avoid changing priorities of product often. If you make a promise, and turned out you couldn’t make it later, users would be upset.

Again, in the “getting real”, it is recommended to say “we’ll think about it” basically.

“Think about it”… this carried me back to my childhood when I was blaming Japanese politicians always saying “I’ll think about it” without promising anything. I now know why they needed to say in that way somehow.

Basically, I try not to promise anything to users, because I can never tell what I am going to do for my products in the future.

Even if I expect I would definitely implement one feature, I try not to say I am working on that.

However, I feel bad to say the same template sentences like a robot to users, so at least I try to understand why users request some features and explain my situations sometimes.

How do you say why?

It’s important to say “why” to understand the backgrounds of each requests well. Some people say we should repeat why, so we can dig into the needs behind the requests.

However, in the real world, it is easier said than done. Don’t you think you get tired if you are asked “why, why?” when you just request one feature?

In this case, I try to confirm reasons, just like, “you are requesting this feature, because you have this issue, am I right?”

I believe it’s less annoying to users instead of being asked with why, and of course, this attitude can minimize risks of implementing new features without knowing the real reasons behind feedbacks.

Priorities…

It sounds convincing when you say that “I cannot do that since I should protect simplicity of my product…”, but, it could not be a real reason for not doing something in many cases.

Sometimes, implementing some feature takes too much time, or I cannot see any corresponding benefit for the time. Especially when you are selling apps for a few dollars with one time purchase business model.

In this situation, it is much harder to explain this to users.

Having said that, it’s really worth listening to feedbacks from users as much as you can, since you can learn something you have never thought of. Even if you get opinions you expected, that means you are validating your hypothesis.

If you seek for feedbacks from nowhere, it’s gonna take a time to meet people which are your target users.

When they come to you and ask for something, this is a golden opportunity to learn a lot and get valuable insights.

Plus, you feel great when you see people who actually care about your product. This is why, I set a feedback box using Helpshift for Taxnote, Zeny, and other apps.

I understand you want to avoid getting support emails for apps when you stopped updating in the future, but, at least when you are working on that constantly, it’s worth putting a feedback box inside of your apps.

Related articles

This is a really good article related to this topic.
PRODUCT STRATEGY MEANS SAYING NO

“Avoid Setting Publicly Visible Deadlines” part of this article.
Running A Software Business On 5 Hours A Week

37 Signals Getting Real. One of the best in product development.
https://gettingreal.37signals.com/GR_arb.php

***
I got an email from Gergana of SANSMAGIC saying this issue resonated with her. Her book about how you can reply to customers includes very detailed tips on this topic, and she shares her own experiences in the real world.
http://sansmagi.cc/resources/

*I make an Text to Speech app, one-tap timer and more. About Me.