74

Here's the problem I'm facing:


Quote From Project Manager:

Hey Spark, I'm assigning you the task of developing a framework that could be used for many different iOS applications. Here are the requirements:

  • It should be able to detect the thickness of the thumb or fingers being used to manipulate the UI.
  • With this information, all elements of the UI should be arranged & sized automatically.
  • For a larger thumb, elements should be arranged nearer the center of the screen.
  • For a smaller thumb, elements should be arranged nearer the corners of the screen.
  • For a larger thumb, all fonts should be smaller. (We're assuming an adult in this case.)
  • For a smaller thumb, all fonts should be larger. (We're assuming a younger person in this case.)

Summary:

This framework is required for creating user-friendly user interfaces programmatically. The framework should be developed in such a way that we can use for as many projects as needed, so it must also be very developer-friendly.


I am the developer given this task, so my questions are as follows:

  • How can I explain that these requirements are a little ridiculous?
  • How can I explain that it would be better to concentrate on developing actual projects?
  • How can I explain that even if this were possible, I wouldn't recommended developing such a thing?
  • How do I say NO to this project politely, gently, and respectfully?
  • How can I explain that even for a developer with 3 years of experience, this might not be possible?
19
  • 7
    You will get lots of brownie points by not all these requirements "silly" and avoid the worst "no". Explain that the iOS devices do not support this sort of functionality.
    – Ramhound
    Nov 21, 2011 at 12:59
  • 26
    How do I say politely, gently & respectfully NO to this? Another piece of advice I should give you, to have some control with your bosses, you should always let them come to their own conclusions. If they order you, never say no, just explain the facts and discuss the problems. Try to get them to realize how stupid their requests are, because they may not know the details. They will probably see that it is a dumb idea and give you a different task, and you NEVER had to say NO. I never say NO and I get dumb requirements all the time that never happen.
    – maple_shaft
    Nov 21, 2011 at 13:11
  • 151
    I thought that the part of the requirement you were complaining about is that they referred to you as Sugar. Then I saw your username :) Nov 21, 2011 at 13:28
  • 6
    Nevermind the fact that the 'observed' finger size would change depending on the way they're holding the device. And lending it to people? Moving buttons is terrible, and not just from a client standpoint - how are you supposed to provide reasonable support for this (buttons aren't in standardized locations)? And how do you define a 'larger'/'smaller' thumb - and the correlation to age? Women tend to be smaller (and have smaller hands) than men - would your app need to know gender? And optical problems tend to get worse with age, not better. Nov 21, 2011 at 17:17
  • 13
    Let's try and detect the wrinkle-ratio of the finger to help with guessing the age. Then when you have a large finger with a high-wrinkle ratio, you've got an old person who needs larger fonts. And when you've got a small finger with a high wrinkle-ratio, you've got a kid just out of the bath, and you'll post an error telling them it's bed time, not iPhone time. Nov 21, 2011 at 19:50

15 Answers 15

102

If you get a set of requirements that are physically impossible to implement as the device does not support and cannot support the wanted functionality, you need to explain this to the person creating the requirements.

You should be respectful and explain why the requirements are not possible to implement (i.e. the touch screen cannot distinguish between a thumb, finger or stylus. It does not have enough resolution in order to detect finger width.) - keep things factual, pointing to existing documentation if there is any.

Do not go into any sort of emotional argument and keep cool and professional. Saying to anyone that their requirements are silly is never a winning strategy.

See if you can get an understanding of the actual goals for the feature - why it is seen as a requirement. This could lead you to a different, better feature that will solve the need. (thanks @spoike)

@DarkStar33 suggests in the comments to do the research and provide an actual estimate of how much the project will cost and how long it will take, with the assumption that the result will be too expensive and lengthy to be worth it. Being armed with numbers and the data to back them up can certainly help your case, though I would still look at the business goals to see if they can be met (even partially) in another fashion.

10
  • 31
    +1 keep it factual, also have the project lead explain the actual business goals that this feature has so that it may be salvaged with another, much better, feature and solution.
    – Spoike
    Nov 21, 2011 at 11:29
  • 8
    @Spoike "have the project lead explain the actual business goals" is a great idea, give them what they want, even if they don't know how to ask for it.
    – StuperUser
    Nov 21, 2011 at 11:53
  • 2
    In this case, assuming the goal is to make the application accessible for people who are in some way visually impaired, then it could be solved much more easily in other ways. E.g. letting the user select if he wants larger/smaller text first time he/she starts the app (and later through the app's preferences). Determining age and visual impairment with the size of your finger is quite a stretch, and could be problematic even UX-wise (say old and little people versus young and large people).
    – Spoike
    Nov 21, 2011 at 13:11
  • 2
    @Tom I don't think that's possible... my grandma grew up in the era where hitting the TV was a valid way to fix it..
    – Izkata
    Nov 21, 2011 at 15:06
  • 5
    As a product manager, I can affirm that 1) keeping it factual is important, but 2) asking questions about what they're really trying to do will go a long way. If they believe you understand their needs, they will be more open to whatever you have to tell them.
    – Taj Moore
    Nov 21, 2011 at 16:16
29

These requirements are not silly, stupid or ridiculous. This is in fact very important problem for users of touch screens, that people with larger fingers have it very difficult to pinpoint the target, which is often not understood by little-fingerers.

However, if you find this requirements impossible to implement because device's sensors are not able to measure finger size, just simply write this so: Unfortunatelly, currently available devices do not support such functionality

5
  • I agree that customer needs or wants are never stupid, we are not arguing that point. We are arguing that it is stupid to lay out requirements, a project plan and dedicate resources to a project that hasn't been prototyped.
    – maple_shaft
    Nov 21, 2011 at 14:19
  • 11
    Well, I'm sorry lechlukasz, but this time I think they're actually silly to no end. Even if the platform exposed the oval pressed in the touchscreen so that it were possible to calc the centroid, the idea of a dynamic UI based on finger thickness is a bit "exotic". As a user, I would not like to be limited to a single-finger-per-session policy, and I'd like be able to press the screen with a finger at a time, with a capacitive pen or even with other parts of the body if I feel so XD. Nov 21, 2011 at 15:30
  • @maple_shaft - seems like this bullet point list of features is only sufficient enough to create a prototype.
    – JeffO
    Nov 21, 2011 at 15:55
  • 1
    I agree this would actually be a useful framework, and, if not useful then extremely cool -- which probably counts for more in the Apple world. You just need a "calibrate finger size" widget and the rest should fall into place. Nov 22, 2011 at 3:41
  • 1
    I think you can do this with current technology. You would need a specific application to calibrate finger size and store it statically, rather then the completely dynamic measurement envisaged but otherwise its doable. Windows has tailored its windows and icons to screen size for years now so that side is well known. Nov 22, 2011 at 3:44
16

I'm going to play Devil's Advocate here a bit and say that I think it's actually technically feasible to measure the size of a person's thumb. The iPhone is a multitouch device. For calibration, you could instruct the user to place their thumbs or two fingers on the screen side-by-side, and measure the distance between these touches.

Of course this would require testing and experimentation to see how feasible my intuition is. Perhaps the thumbs would have to be dragged across the screen to get a better reading.

That said, there are serious usability and implementation issues.

  • What if the device is shared? When does the calibration happen?
  • How can you dynamically determine the position of the UI elements arbitrarily across all applications built with the framework? Obviously each app will have a different UI and different layout.
  • A simple survey of current iOS apps shows that the well designed ones use all the horizontal space available, and already space elements such that important buttons are as large as possible and placed near the edges. The full width of the device is used for lists and layout, obviously.
  • Even if it were possible, what is the cost/benefit analysis? How much would be gained from such a system compared to standard UI controls? Wouldn't it be easier to have a simple toggle control for font size like many apps already use?
12

What you do is treat it seriously and come back with an estimate of how long it would take to do and make sure the estimate is very high and very detailed so they can't dispute the high numbers. Once you have shown it won't be economical to do they will leave you alone. Make sure to point out whci specific tasks are not currently supported by the hardware and may or may not even be feasible to do. Do forget to add costs for any sort of specialists additional people you might need for a project of this magnitude.

6
  • 2
    Yep, this is the right approach. Never say "No". Simply analyze the problem and propose a solution that would work, along with time estimates. So, what's the time estimate for altering iOs to dynamically calculate finger width? Maybe 2 years for about 10 OS developers. There's your estimate! :) Nov 21, 2011 at 16:02
  • In this case, you'd have to agree it with Apple, which means referring it to legal, and all kinds of things outside the purview of software development. In this case, I would say that you can say "It is impossible, given the limitations of the hardware, which we do not control. We will need to enter negotiations with Apple."
    – deworde
    Nov 21, 2011 at 18:26
  • 1
    @deworde - I hate the word "impossible" people 20 years ago thought a great was "impossible" how about saying "currently not possible with provided hardware".
    – Ramhound
    Nov 21, 2011 at 21:24
  • @Ramhound They're your business planners, not your kids. Don't sugar-coat it for them to protect their hopes and dreams, GET THE REQUIREMENTS OUT OF THE SPEC.
    – deworde
    Nov 22, 2011 at 10:28
  • 1
    Add 2 more years, 100 hardware engineers and a 50 million dollar R&D lab to invent the hardware to sell to Apple to your estimate that, yes, this could possibly be done.
    – hotpaw2
    Dec 8, 2011 at 7:04
11

People at Apple already deeply thought of all these things and they didn't come up with a resizable interface depending on thumb/fingers sizes.

As a user, I would hate moving targets under my fingers.

4
  • 2
    I used this argument when asked to write a universal meta-query for a poorly designed Access database. (I.E. a system where any user could query anything arbitrarily without having to use the query builder) I said "If this was possible, Microsoft would have done it, and they'd be advertising it everywhere. Nov 21, 2011 at 16:55
  • @chris: that's exactly what I say anytime someone wants a do-everythin report wizard. If it were possible, Access would have had it back in the early 90's
    – Neil N
    Nov 21, 2011 at 21:01
  • 4
    -1, 'because Apple didnt do it' isnt a good reason not to try something new. It may be that its an incredibly stupid idea and/or physically impossible. Or not. But I'm not seeing where the harm is in trying it if his bosses are willing to expend the resources. Nov 21, 2011 at 21:41
  • 2
    @GrandmasterB - My guess is that Apple did do it, then rejected it. Anyway, a little bit of common sense tells that from a usability point of view this is far from comfortable. I don't need a boss with such ideas.
    – mouviciel
    Nov 22, 2011 at 8:29
10

If you are worried about getting in trouble for being given impossible requirements, then the best choice is to tell them immediately that it is impossible. The longer you let them build a business plan on an impossible project the more likely they are to blame you for the failure of the project.

Above all, try not to worry about things that are not your fault, we all have enough to worry about that we do have the ability to control. If somebody were to hold you responsible for such a project failure then it is injustice against you. Do you believe in Karma?

3
  • Yes I do believe in KARMA ? :) Nov 21, 2011 at 12:58
  • 1
    @sugar I do too! If they don't listen to you they will fail.
    – maple_shaft
    Nov 21, 2011 at 13:06
  • Don't say its impossible say the operating system does not provide this information. Since in the case of an iOS application you can only use public methods you are limited to what the operating system officialy supports. If this was possible they would have provided this to the framework and thus the user wouldn't even question this requirement.
    – Ramhound
    Nov 21, 2011 at 21:22
8

One way of diverting the unreasonable request is by helping the client understand the nature of the problem they're trying to solve. Through a planning interview technique colloquially known as "popping the why stack", you continue asking "why" recursively (in a polite, intelligent way of course):

One important tool for both getting communications going and "cutting to the chase" of specific issues is what Barrett calls popping the "why" stack. This is simply to keep asking the question "why is it done that way?" about project requirements. He gave an archetypal example of what the technique can unearth: "I once worked with a client where there was a requirement that data was printed out at a particular stage in the process, so I asked why" he said. "The answer was that the department receiving the data needed to key it in. It had never occurred to them that the data could be transferred to their application automatically."

The goal is to arrive at the core business value of the feature:

  • Protect revenue
  • Increase revenue
  • Manage cost
  • Increase brand value
  • Make the product remarkable
  • Provide more value to your customers

(Items from Cucumber wiki)

If the feature doesn't fit one of these categories, it may help the client to see that there are either more important things to focus on, or through this thought process you may be able to advise them on how to address the problem they're trying to solve in a more meaningful way. Often the real problem lies at a higher level of abstraction than the problem they've requested you to fix.

To use your example of scanning thumb sizes:

Client: We want to detect the thickness of the thumb or fingers being used to manipulate the UI.

Dev: Why do you want to do that?

Client: Because when I try to tap these small buttons I often hit the wrong thing, and our software is used by a lot of construction workers with big hands like me. If they could calibrate the UI for their finger size, it would make it easier to use.

Dev: Ease of use would certainly be valuable to the customer, but why would they want to calibrate the UI? If the people using this are known to have big hands, why not adjust the design for that use case?

Client: I never thought of it that way, I suppose a cleaner design would work just as well for people with small hands too!

1
  • 4
    +1 For popping the why stack and quote: Often the real problem lies at a higher level of abstraction than the problem they've requested you to fix.
    – Spoike
    Nov 22, 2011 at 9:26
7

Disclaimer - I don't know whether your request is possible, and if it is possible then you need to determine how long it would take and provide that feedback to your manager. But I'm writing this answer with the assumption that it is not feasible, at least using the standard framework - and I'm extending my answer to the more general case when you really can't or shouldn't do something.

Just say NO.

There are many 'never say no' answers in this thread, which I believe is a soft and submissive attitude. Think about it this way - I'm the technical expert in this team, and my other team members are trying to do something that I think is unfeasible, over-complicated, potentially not possible. It's my responsibility to say no.

Of course I can & should say no gently; I can "strongly recommend against this" while offering to "investigate whether it's possible" before saying no. But I'm ultimately going to say no because that's my job.

There are so many analogies to this

  • My Accountant, I want you to put my Thanksgiving dinner down as a tax deduction
  • Mr Chef, I would like my chicken left on the counter overnight and served raw, please.
  • My Lawyer, I want to sue my children for not tidying their bedrooms
  • Mr Mechanic, please install a turbocharger on my electric car

You can ask all of these people to perform tasks that they'll know are silly, wasteful, dangerous or wrong. And you would expect all of them to advise against these actions and ultimately refuse (at least I'd hope so). If any of these professionals replied 'Hmm okay I guess we can do that' - without giving me a straight up "This Is A Bad Idea" - then quite frankly I wouldn't want to hire them anyway.

Your colleagues will value and respect your honesty, and you will save everyone a lot of time and money if you provide useful feedback rather than going along with something you know won't work.

2
  • 2
    note: I'm addressing the question "How should a developer reject impossible requirements". Nov 21, 2011 at 22:43
  • More power to you.
    – ThomasX
    Dec 8, 2011 at 10:25
2

It should not be too hard to tell your client that you cannot implement something your target platform does not allow you. But take a step back and ask yourself , what is the logic behind these rather riddiculous requirements? From what I can read they are very concerned about user-friendliness. Then ask them, dig a bit deeper till they say the same thing to you: "we want a user friendly interface". Then guide them into what is doable and what is not. Tell them that if they want an easy user interface there are easy (and cheaper ways) such as letting the user set the font/icon size (I assume that i possible on the IoS). Maybe you can let the user control the font size/icon size and arrangement for the application through a settings tab? That should be easier (and more accurate!) than trying to guess the age of a person on the thumb size! The last thing your manager would want is unnecessary, bloated, hard-to-maintain code that achieves the same thing that the os already provides. Tell your client that users would prefer controlling the application rather than the application controlling them in ways that may infuriate them.

1

My response would be that I would start looking into some of these untried technologies and let them know if it is even possible. Based on those discoveries, a potential development plan can be started.

I don't think you'll be able to tell one person's thumb from someone elses, but you may be able to get enough dimensions from the fingers to know when they're using the thumb. The real problem is because of the angle of the thumb it may not touch any more space on the screen than others. No one ever uses a phone with their thumb and places it flat on the screen like you're having your thumb print taken.

Leave the company. Figure out how to do it. Sell it for a lot more money than you're making now.

1

When it comes to requirements I usually do it like this: I try to estimate how long it would take to realize a specific requirement.

In case of requirements that might be impossible, ask for some days or whatever time it takes to find out whether it is possible. In your case the question is: "Is it possible to determine how thick the user's finger is?"

In fact this question is even a bit more complex: "Is it possible to determine how thick the user's finger after the first touch in less than 200 milliseconds to allow for a immediate interaction?" (replace first by 2nd or ...; and 200 ms by 300 ms or whatever...)

Maybe even answering this question takes one month. Maybe even if this is more or less feasible, it takes a super complex algorithm that only works good in 80% of the cases.

You see where I'm going?

People often make wrong assumptions about possibilities because they have low expertise and experience regarding the field in question. Therefore you cannot argument with intuition, but you need facts.

If the other stakeholders realize that this feature would take 2 man-years and requires the iPhone 10 to arrive before 2014, there will quickly downscale their requirements.

1

This sounds complex but not impossible at all; the point that the touch screen cannot distinguish between a thumb a middle finger or a stylus is moot; the user is asked at initialization (session startup, whatever) to place a thumb, then a middle finger, etc. to calibrate the sizes (make some statistical averages) using several movements, etc.

0

I'd consider trying to solve the root issue in another way before saying it can't be done.

For instance, if the user often tries to click a small button and misses, you could watch the area around the button and use that to re-calibrate all other clicks.

Presenting a creative solution like this is probably what they are after more than asking you to magically figure out the width of a finger (which you can inform them is not in the API).

It may still be difficult--placing an area around buttons to detect misses--so estimate more hours.

0

Don't outright say no as that would hurt his feelings. Just make it clear that due to technology constraints that 60% of the time it will work every time.

And once he realises the impracticality and cost involved in such an undertaking, suggest a more practical approach within his budget such as having a setting that allows you to change text size. And the Russians took a pencil into space.

Try to get him to state the problem and requirement and not the solution and design for future projects.

-1

What I like to do, is to approach the problem from a team perspective. In this case the project manager and I need to come up with a solution. I also like to show that I come with an open mind. If I hear what I think are hearing impossibilities, there is a chance there is a misunderstanding between me and the project manager. Or perhaps we have not reached that aha moment.

Once we decide to take a leap and have an open conversation, I find it easiest treating the problem as an economic one. In technology almost anything is possible given an infinite amount of resources. Discussing what it would take to do, many times is the easiest way to respectfully "say no". And that would be the way to clear any possible misunderstandings. Although, to be honest, we are not quite saying no. And, what is the purpose of saying no anyway. If the work is not worth doing, it does not matter whether we want to do it or not.

Not the answer you're looking for? Browse other questions tagged or ask your own question.