Friends and family feedback

[elizabethbarr]

Due Aug. 3

[elizabethbarr]

Friends and Family Feedback: Walk through three friends or family members each of the three tasks and solicit candid feedback on the process. Make adjustments as necessary to improve the paper prototype of the tasks before each feedback session. Write a four paragraph analysis of each task and what was learned through the paper prototyping exercise.

[elizabethbarr]

[Background: My app, saves restaurants time by helping them make better hires. Currently, it's nearly impossible to vet a tipped employee – servers, busers, bartenders – in any meaningful way as turnover is so high as to make even the act of calling for references too burdensome.]

The three tasks I focused on in my prototyping exercise were the workflows for the employee to sign up, create a profile and search for jobs; the restaurant to sign up, create a profile and look for applicants; and the endorsement or rating mechanism for each employee.

In addition to my working group, I walked four friends and family members through the prototype to solicit feedback.

1. On the employee task (the series of screens that will allow an employee to either sign up, log in, create a profile or search for jobs), most everyone who looked at the prototype were able to follow the flow a new user would use to navigate the app. There were a few things they noted that needed emphasis, including a clear message on the landing page (at least) that the app is free for employees to use.

The logic chain in this task also broke down a bit because it wasn't clear exactly where an employee would go to apply for a specific job. That was fixed with the proper screen for that, but it also brought up other questions about the general flow that I also addressed, mostly clear "call to action" buttons or tags on each and every screen a user sees.

Whether the employee is able to see his/her endorsement(s) or ratings also sparked good discussion, especially in our working group meetings. That employee rating is currently only visible to restaurant owners and until I find some compelling legal reason to change that, I am going to leave it as it is.

We also discussed search functionality, as being able to search and use filters will be a major benefit of the employee when using the app. My rough mockup shows the job search filters currently as: city/state, specific restaurant and position.

1. For the restaurant owners, there seemed to be more questions about how the app would be utilized. The first question surrounded the archive of applicants that a subscribing restaurant would be able to see. That would be an archive of applicants that have applied for a specific job posted by that restaurant. While the job ad would expire after 5 days, the applicant's info would remain visible for as long as the restaurant is a subscriber. Which means that a $50 job ad could possibly generate a pool of applicants the restaurant could draw from at a later time, making future job ad purchases unnecessary. Cannibalizing one's own market is never good, so I need to continue to think through how job ads and the archive of applicants will work for me, not against me.

There was not a clear place for restaurants to pay their subscription fee. We discussed pricing models for monthly and yearly subscriptions, as well as "freemium" pricing where a monthly subscription is free with the purchase of a certain number of job ads, possibly.

Additionally, it was not clear on the landing page while this service is free for employers, restaurant bear the cost. Also, the "hero statement" on the landing page seemed only to appeal to restaurants. As they are my real market (and the employees only indirectly or secondarily), it's important I communicate the app's time-saving benefits, but it also needs to really capture the eye and attention of the employee in a way that does not arouse suspicion. It shouldn't look too much like an HR tool but a social media platform that will help them find the job they're looking for.

We also discussed security for restaurants and their information and archive of applicants. What sort of technology under the hood safeguards both the restaurants' profile pages as well as keeping access to their applicants exclusionary?

Another point echoed by a few people was the issue of who can subscribe to the service on behalf of the restaurants? One security check method would be to only allow those creating an account with the restaurant's email address to subscribe. This isn't foolproof, but it would be a quick and easy way to ensure most subscribers do indeed have the right to be creating accounts and hiring for that business.

1. The task that fueled the most questions and discussion was that of an employee ranking or endorsement from restaurant owners/hiring managers. Of course, the most widely known example of this already being utilized would be LinkedIn's method of endorsements – both by specific skills and written recommendations. But those come from peers and colleagues. It gets trickier legally when those ratings are coming from employers. And even trickier when the issue of references are coming from an employer who terminated the employee in question.

A previous iteration included a place for restaurants to provide yes/no answers to very specific questions (such as, was employee terminated for cause? did employee have history of tardiness or absenteeism?), but the question then turned to: What value is this to a potential employer? If turnover in the restaurant biz is as high as I've said it us (can be as high as 300 percent), then who has the time to wade through this and use it to make a determination about hiring? My solution was providing information, but not a clear time-saving course of action.

The app does allow restaurants to indicate the duration of employment, down to the day if necessary. That is an important piece of information for a potential employer. But it's possible that does not tell the whole story. We wanted to find a way to off-set that if need be – to allow a restaurant to truthfully say "Jane Doe only worked here three days" but, if Jane Doe gave proper notice, if it was simply not a good fit for both restaurant and employee and she left on good terms, not to ding her on any sort of rating system.

Another solution was a radio button the restaurant would check that says simply, "I would hire this employee again." After speaking to a few people directly in the restaurant business, that seemed to be the way to go, with one change, making it "Is this person eligible for rehire?" That, come to find out, is the magic question in the HR world and gets around any and all legal issues that involve giving references for former employees.

So now the challenge is to combine the duration of employment with the yes/no response to "Is this person eligible for rehire?" to create an algorithm that will instantly give a subscribing restaurant the information they need. A genius idea came from a restaurant owners who asked if those two pieces of info (duration and "eligible for rehire?") could be used in an algorithm that produced a red/yellow/green indicator on the employee's profile page. (This profile page is not visible to the employee, remember.) This seemed to be the answer I was looking for: combining objective, measurable information about an employee's tenure with the legally kosher "eligible for rehire" yes/no, creating an instantly recognizable color rating that allows the restaurant to make a fast decision on this potential hire.

Handing that task over to my working group and friends and family saved me weeks or months worth of research and iteration. Genius.