Jobbie
Connecting people to get things done.
When it comes to decorating for holidays, my brother and his wife really get into it. This Christmas they are in a larger home and were recently talking about the hassle of putting up Christmas lights. He thought about doing it himself but had trouble finding the time, they are busy with four kids under the age of six. Next he looked into paying someone to do it but services in the area were expensive. So he asked if I wanted to do it for a little less than what professional services charged. Win, win. He saves money and gets the lights up. I get a little extra cash.
That is the basic concept behind Jobbie. There are lots of sites and apps that match people needing a task done with others willing to do them. Unfortunately, most of them lean towards more complicated and professional level work.
The Challenge
For this project I worked with a group of fellow students in the UX Design course at DevMountain. We worked to create a service for simple tasks. Tasks that don’t need high level skills such as hanging Christmas lights or mowing lawns. We also teamed up with three developers from the iOS developer course at DevMountain. And we only had three weeks to research, design, and build the whole thing, talk about pressure.
The Process
We used the Five Planes of User Experience as a guide to our approach. First is strategy. Finding out who our users are and what they want. Asking questions and talking to people. Second is scope. Defining what content we need to solve user needs. Third is structure. Designing user flow and patterns. Fourth is skeleton. Building a basic outline, creating the sequences and flows. Last is surface. Making it look pretty with color, typography, spacing, etc.
Strategy and Scope
The first thing we did was start talking to people. I created a survey and sent it out on different social media platforms. From the survey I received contact information for a few people who had used similar services. I reached out to ask more in depth questions. My teammates also reached out to others in their network who had hired or been hired for these types of tasks and services. Here’s what we learned.
Main concerns about posting a job:
- Will the person I hired do a quality job?
- Will the person I hire be honest and trustworthy?
Things that would help our users:
- User ratings, reviews, and references
- Visible bio and experience(it makes them seem more like a real person)
- Profile pictures (seeing a person before you meet them lowers anxiety)
The majority of people seeking jobs only cared about the money. So we created a persona and focused more on employer needs.
Referring to Vernon helped us keep focus on our user’s pain points while creating a user story board. During this step we started involving our developers which was very valuable in saving time on this project. We didn’t want to create anything outside their ability to build under the time constraints. It also helped increase their investment in the project.
Structure
Taking our ideas and input from the developers we divided up the different pages and flows. I worked on the section where a user could view all his or her jobs. There were eight different categories of jobs which I’ve listed below. I had to figure out how to name and organize them.
- Jobs the user posted
- Jobs the user posted and others have applied to
- Jobs the user posted and assigned to someone but are not complete
- Jobs the user posted and completed
- Jobs the user has applied to but not been assigned
- Jobs the user has been assigned but not completed
- Jobs the user has been assigned and completed
To help resolve the issue I performed open card sorts. I gave participants items from the different job categories and asked them to group them. Then I asked them to name the groups. The end results were as follows:
- Active: Jobs that are being completed either by the user or someone the user assigned to the job.
- History: Jobs the user has completed or posted and had someone else complete.
- Applied: Jobs the user has applied to.
- Posted: Jobs the user posted but has not assigned to anyone.
Skeleton and Surface
After figuring out the categories I sketched out a few ways to display them. I decided on having four tabs at the top because it allows users to move between them and know which tab they are in. Next I started creating wireframes. I uploaded them to InVision and tested the flow moving from category to category. After receiving positive feedback I moved to high fidelity following the style guide we created as a team.
Ratings and Reviews
Because ratings were so important we made them mandatory. At the completion of a job both the employer and the employee rate each other. This holds job seekers accountable for the quality of their work. It also allows them to build a reputation and increase the likelihood of being hired for future projects.
When a job seeker applies for a job they show up in the employer’s applicant list. The employer can then view ratings and comments from a user’s previous jobs.
Looking Back
Due to the time constraints we were under there were a few features that we had to omit. If we had more time there are two I would have included.
First is a map view. There would be a pin with a radius showing the general location rather than an exact spot. It allows employers a little more privacy. No one sees the employer’s address until they are hired. The radius around the pin shows the general location rather than an exact spot.
Second is in-app messaging. This also allows greater privacy. Users don’t have to display their phone number if they choose not to and communicate their needs within the app.
What I learned personally
Working with developers is challenging…
This was my first exposure working with developers. There were two main things I learned from the experience.
Constraints and limitations: I had to think about constraints a lot more. I was learning UX and the devs were learning programming. Both of our abilities were limited. We only had three weeks to design and two more for the devs to build. Prioritizing functions and elements was crucial. We had to stay in constant contact to be aware of each other’s progress.
Communicating concepts: The devs we worked with were great. They invested themselves in the project and worked hard. They also had opinions on what the app should be. Communicating the purpose of the design process helped them understand why some features were important even though another option was easier.
…so is working with designers.
There were three of us working on the same design. We had different opinions on what color to use, spacing, naming, pretty much everything. Some issues we solved through testing. Others required that I choose my battles. If it wasn’t an essential decision, I didn’t push my opinion.
An example of a disagreement was the design for the landing page tiles. We started with Design A but disagreement on the design caused us to revise it. That led to testing, refinement, more disagreement, more testing, and more refinement. The process validated some of my ideas but it also showed me I was wrong just as much, which was sobering. Eventually we landed on Design F. We still didn’t agree on everything but decided it was good enough so we should spend our time on other things.
Conclusion
On the whole. This experience was a great opportunity for growth. Remembering to prioritize under time constraints, keep in constant contact with my dev team, and avoid letting my opinions skew my vision are all valuable lessons I will apply on future projects.
In the app store
The app recently made it to the app store and is available for download. Due to time constraints on our dev team, the app is a little different from the designs I’ve displayed.
