WinterMilestone 2 Jinesh
- 1 Learn about Need Finding
- 2 Attend a Panel to Hear from Workers and Requesters
- 3 Reading Others' Insights
- 4 Synthesize the Needs You Found
Learn about Need Finding
I discovered this field of Human Computer Interaction with the help of Scott Klemmer's Coursera HCI lectures. Below is a brief summary of these lectures and other lessons in Needfinding.
observing people to find out their needs, goals and values need: existing problem finding need yields untapped opportunity for design observing people helps build empathy, which is something that I have found to be really important as a data science enthusiast, unless you put yourself in your users shoes and understand their problems you cannot build effective solutions for them.
Deep Hanging out : By spending time with people while they do their work and live their lives you can get beyond the surface of what they say and learn about what they actually do.
What do people do now what values and goals do people have How are these particular activities embedded in a larger ecology similarity and differences across people other type of contexts
Process vs Practice Apprentice :
- Set up partnership with the people to be observed
- Be taught the steps in the process
- observe all of the practices
- validate what you are observing with those observed as you go along
- Look for workarounds and hacks
- Errors are ‘Goldmines’
Walmart lessons: pay attention to what people do rather than what they say don’t ask leading questions
Verbs not nouns Do not mix observation with interpretation
- chose the participants wisely
- Approximate if necessary
- importance of being curious
Attend a Panel to Hear from Workers and Requesters
Attending the panel discussion was very insightful. It allowed me to understand the human perceptive which no amount of reading could have done. After the meeting was over I interacted with some of the workers on slack. The observations from both the meeting and the conversations that followed are listed below
cooperation of fellow workers
unpredictable workflow : When do high paying, interesting HITs arrive → Need some timetable : People forced to leave everything and switch to turking, good in the sense that it gives a certain level of freedom, the downside is that you are not guaranteed to find work when you have the time window
Worker rating a big concern : script to predict worst case scenario . Hinders the workers willingness to try out tasks from new requesters email and check with requesters to check out their nature and helpfulness of response to determine if to work on their HIT
- Need accurate estimation of time needed, given estimation are totally off (deliberate + unconscious inaccurate time reported by Requesters) → solution used: experience + relying on time reported by other workers
Workers reported time also varies person to person ( typing speed etc)
prefer to perform certain kind of tasks based on their abilities (good typing → does not prefer bubble survey)
variable earning → based on how you budget your time ( spending time on small tasks vs wait for big tasks) financial uncertainty a big problem
employ scripts and hacks
- death for new workers
- access to decently paying work depends on working
- Need for feedback, Requesters reject based on intuition → time taken etc
- share screenshot with Requesters and ask what went wrong and try to rectify that (desperate to avoid rejection)
Describe your experience in 5 words
- anonymous frustrating complicated tricky
- absolutely unpredictable great and terrible
- power frustrating empowering lonely tiering
Some sense of competition between workers to get to the good tasks before others
- allows rapid deployment
- important - understand the task to ensure a correct and clear description of the task
they use a kind of prototyping method by releasing a small batch and checking results → depends on workers initiative and participation in alerting and emailing
- irritated by spam mails from the workers, don’t have time to interact with workers on a large scale
- reputation of requesters also important to ensure good workers engage with your tasks
- fairness to both Workers & Requesters needed
- no personal connect with Workers (interacting with serial numbers)
- Need ability to build your own template
- gold tasks to weed out spammers
- tend to reject workers in between to show them they are doing it wrong
5 Words to Describe your experience
- enabling scientific research
- dynamic futuristic enabling humans
- power frustrating empowering lonely tiring
Here are some excerpts from the discussion
Reading Others' Insights
Worker perspective: Being a Turker
- Care a lot about the pay scale
- angry at someone that suggests that turking can be for fun
- sceptical of the requesters
- clear that they are doing it only for the cash
- In it for the money , don’t really like turking, would be willing to leave for a better paying opportunity
- flexi timing and anytime access important
- Have a feeling of being left out, want to know how is everyone else doing
- feel they do not work hard enough, but are generally positive about their future
- believe they can improve their earnings by working harder
- More experienced turker make more
- Not earning enough
- desperate for money
- going through difficult times → Should be a cheerful platform
- need to know the type of requester they are interacting with
- eager to avoid bad/low paying requesters
- acceptance , fair pay important → Money
- Strong sense of community, want to help other turkers out by telling them which requesters are good
- In a sense also want to levrage the bond of the community to fight back/ issue a blow to the requesters who have wronged them (in their mind ) and against whom they are generally powerless (No other means of retaliation)
- Have a sense of pride and want to be respected
- want to be taken seriously in the forums
- want other turkers to believe them and follow their advice ( whom to avoid/ not avoid)
- Requesters feel that workers are lazy and not worthy of the pay.
- The primary reason of their using AMT is their laziness (Their fault) and could be in a better shape if they took control of their lives
- frustrated that they cannot get back at the requester
- want a way to appeal blocking
- Want to feel empathy from the requesters and want their work to be valued by them
- Communication with requesters important, want to feel needed
- Requesters availability and responsiveness important as it not only improves the work speed (questions etc ) but gives a psychological feeling of being needed/valued
- Want to trust (new) requesters, but are vary as they have a lot to lose (time, potential money , ratings etc )
- The amount of time it takes to receive approval is important, do not like the uncertainty.
lack of information on the part of the requester is viewed as a big negative
- Do not care attitude towards requesters well being, but willingness to help if they reach out.
Believe if requesters are cheated it is their own fault
- Open to changing their minds about requesters
- Open to admitting fault and not holding a grudge against the requester, if their fault is explained to them and they deem it to be fair
- workers tend to look at the compensation as a package, The pay combined with the ‘benefits’ of being able to work from home , whenever they want etc.
- Searching for a good HIT is critical to them; time means money
- Are sceptical of change in the platform (bought by academics and journalists interfering)
- Have self esteem and do not want charity/ do not want to be ‘rescued’ by people whom they see to be better off.
Worker perspective: Turkopticon
- Quick Payment is highest priority for them.
- If a worker's rating drastically falls, it is hard for him/her to pick it back up.
- Workers also take a risk when they accept a job because their work is compared through an algorithm that may or not be functioning correctly. And if the algorithm is incorrect, they won't get paid.
- Valid argument must be present for rejecting a quality work.
- Majority of the work done by worker is treated unfairly.
Requester perspective: Crowdsourcing User Studies with Mechanical Turk
- Skill set or the geographical location of the worker is not known to the requestors.
- Faster response to the work done leads to high skill growth for worker.
- Standardization would mean less guess work on the side of both requesters and workers
- Worker can choose to perform tasks of varying difficulty.
- Workers must learn the intricacies of each requester, including the different interfaces for their tasks and the various quality requirements for each requester.
- Workers are forced to constantly adapt due to the lack of standardization of tasks.
Both perspectives: A Plea to Amazon: Fix Mechanical Turk
- People are demanding for evolution
- Core Structure is weak.
- People’s Problems have never been addressed properly.
- Hands-off approach not properly issued.
- Poor Interface and ill repute system.
- Difficulty with respect to finding full time worker.
- Proof of Authenticity to every new requestor.
- Lack of Interface Standardization.
- Problem regarding things that have to be built from scratch.
- Easy manipulation to worker’s profile.
- No one is trusted due to bad review of some people.
- Redundancy is more.
- As long as the work is done properly, the reputation of the worker simply does not matter.
- Requestor can do whatever they want to do!
- Trial and Error method is followed by the workers for a new requestor.
- New Requestor tries to give a big task but can’t get good results as workers doing that task are spammers and inexperienced which results in less number of new requestors
- Progress of payment not seen by worker.
- Rejections are not verified.
Synthesize the Needs You Found
List out your most salient and interesting needs for workers, and for requesters. Please back up each one with evidence: at least one observation, and ideally an interpretation as well.
A set of bullet points summarizing the needs of workers.
- No less nor more money should be paid to the worker.Decision should be taken on basis of amount of work they did.
- Need the ability to search HITs according to the requesters who posted them.
- Complete schedule of payload should be provided to worker prior to the task.
- Base rating should be established.
- Time Requirement factor should be focused more.
- Workers need some leverage over requesters. In the current set up requesters hold all the power in the relationship, and many of the papers noted the lack of some kind of way to rate requesters meaningfully.
- They need to have a data dashboard tools at their disposal which can give the different kind of information that is not readily available (eg how many rejections can they sustain to maintain their rating, Alert them when certain kind of HITs become available etc). Basically data for which veteran turkers write scripts should be easily achievable, even to the newbies.
- Need a mechanism for shielding them from rejections, a redressal mechanism where they can understand why their work was rejected and contest wrongful rejections. A mechanism where the whole process is not so opaque and their dignity and self-worthiness is upheld.
A set of bullet points summarizing the needs of requesters.
- Requesters need to access to workers who consistently produce good results. One of the requesters mentioned in the panel that he would actively reach out to communities like TurkerNation to discuss work. Requesters seem to be willing to pay for good results but feel distrustful due to the relative anonymity of the current set up.
- Authenticity of the work should be verified properly in order to gain the attention of good workers.
- Better System to tackle untrustful answers.
- Requesters need to reduce the amount of work they do in order to get good results. Evidence: In the paper, "A Plea to Amazon: Fix Mechanical Turk", the author reported requesters building their own quality assurance system, ensuring qualifications from workers, ranking workers according to quality, etc. Interpretation: Requesters have to invest a lot of time into maintaining the quality of results that they get back from workers.
This milestone was completed by @jinesh