UI/UX Passion Project | Summer 2018
Students starting out in their tech career with little experience have a difficult time discovering tech companies to apply to. Since knowing what companies and positions are out there is the first step on the application process, this is a pain point is an important one to address.
The challenge is to design a platform for students to easily discover tech internship positions at tech companies, and keep track of their application process.
Although I was tempted to jump into sketching and wireframing given the short amount of time I had to work on this project, in order to come up with the best design for a consumer facing product like this one, I had to first understand:
- What problem are users currently facing
- Why are current platforms not working well
- How can I fit into the desired product-market?
- Setting the stage
- Final considerations
The goal is to design a simple web app that focused on:
- Reducing complexity — Limit the number of actions on each component and steps in the user’s workflow.
- Balancing UI and UX — Not everything needs crazy visuals and animations. Although I wanted pleasing visuals, I was primarily concerned with intuitive workflows and UX.
Although I knew I wanted to make this platform for tech internships, it didn’t necessarily mean only one user type fit into those needs. While thinking of the possible user problems, I began developing some questions I needed to learn from users. For example, I wondered how users are currently looking for tech internships and if they’ve developed workarounds. I also wondered what they valued most in a job (e.g. location, size, experience, pay, etc.). I decided to conduct extensive interviews on 10 of my colleagues and friends who are in the tech space currently in an internship.
Here’s what I discovered:
- Found very little success cold-applying online, usually needed an referral or “in” from friend/connection that works/worked at the company
- Current workflow is: hear about a job from a friend → search up LinkedIn recruiter → send recruiter an email to start application process
- Pay doesn’t matter as much as experience but if the opportunity came, would still choose to work at a “big name” rather than a startup
- Manually tracked process of process on whiteboard or paper
Although I was used to creating personas, I wanted to look into user needs from a Jobs-to-be-Done framework, and finding what users would “hire” my product to do. Therefore, instead of having various personas in specific user segments that ranges from a computer science student to a business grad that’s looking to switch careers, I created a focus point with the job-to-be-done:
To know which companies are out there and if they are currently hiring in a specific position.
I did an in depth review of the current market leaders in finding internships: LinkedIn, Glassdoor, Internships.com, Indeed, Intern.supply, and AngelList.
To summarize findings:
- Most of these platforms were black holes of information. There are pages of postings that are both relevant and irrelevant in every parameter. Users can be immediately overwhelmed by the amount of information presented to them and build up an expected behaviour of ignoring more of the information that they don’t need.
- Things become outdated. As soon as these platforms depend on companies to update the postings, or pulling data with queries that aren’t filtered out, information becomes outdated and applications that are no longer open gets linked to forms that no longer exist. And with that many postings, no wonder they can’t keep up.
- Pain point: many internships do not explicitly post for a certain time period and there’s no good way of filtering by the internship period.
Hierarchical Task Analysis.
I conducted a hierarchical task analysis to better understand and map out how users might go about the process of finding an internship broken down into its simplest steps.
Knowing one of the major pain points of existing platforms is the amount of clutter and almost overwhelming amount of information on each page, I wanted to reduce that to a minimal experience. Although there are benefits of having everything on one page (filters, list of jobs, job descriptions, apply buttons, etc.) the way that most existing platforms have, I saw greater benefit in grouping actions and splitting them up, so that a user has a limited number of actions on each clear and it’s clear when to move on to the next page to perform another “group” of actions.
I focused on layouts and hierarchy of information when planning my sketches. I wanted information to be presented left to right in order of importance and users can get all the information they need at a glance and have a decision of what action to perform next when action buttons presented themselves. I also focused on limiting at-a-glance information to reduce complexity and confusion. This included hiding filters and carefully choosing what’s most important to the user and only display that.
I chose purple as the primary theme colour because it “combines the calm stability of blue and the fierce energy of red”, and is often associated with ambition. Since green and red will be used for success and failure, and blue for information, purple was the colour that best contrasted the standardardized colours and was still highly accessible.
I drew inspiration from Dropbox design by finding simple ways of dealing problems without any distractions. I also opted for a clean almost minimal look without taking away from necessary information and options, you can see this in the spacing of components and simplicity of the decision-making process for users.
I hyper-analyzed iconography to be friendly, welcoming, and contrast existing platforms by being “young and relevant” (it's a smiling briefcase).
After refining sketches, finalizing scope/feature set and putting my ideas on the computer, here are the results.
Jobs Dashboard - The Details
Company & Position Profile
I quickly iterated based on both user feedback and guerrilla usability testing by asking current students looking for tech jobs as well as eating my dog food. From that I made some design decisions that took out pain points and complexity, narrowed scope, and things that I didn’t realize made no sense at all the first time around. Here’s some design decisions and iterations that came from this process.
- I debated back and forth whether or not to have a list to map toggle feature. Although this would provide useful for the use case of finding jobs close to home or in a lassoed area, it would “override” the Location, and making users aware of that added too much complexity. In the end, I decided to scrap the map from the home page and add it to the Saved Jobs section.
- If a company has more than 1 position, I wanted to list the first few then have a show x more link that would take the user to a more detailed list of available positions grouped by company. Although this would have reduced clutter in the home page, ultimately, it didn’t make sense with the action button or displaying the available positions. After iterations, I decided on a 1-to-1 relationship between company and position, which meant there will may be multiple rows for a company with many open positions, it made displaying information and calls to action more clear.
- On the Company & Position Profile page, one of the main goals is to give users the ability to be notified about a position becoming available. My original design did not indicate that the position is unavailable and isn’t consistent with the components on the “notify me” a secondary action with the primary being “apply” which becomes “unavailable” if the job is unavailable.
A major takeaway, although it sounds obvious here, is to take time at every stage of the design process to ask yourself (or even better, test it on potential users!) if your workflows and decisions make sense, because sometimes things just don’t the first time around.
I also admit to sometimes hastily jumping to visual design and putting components together in sketch before I’ve really thought them out. Mockups that didn’t go through iterations of sketching and wireframing just don’t work, and frankly takes up a lot of time.
Scope creep is real!
I’d like to spend the next little while before continuing design, to user test on potential users (and non-users) to find pain points and what questions they have at each step of the workflow. I think formal user testing with a high fidelity prototype is very valuable before moving on to adding details. From that I hope to potentially kill features before setting resources to build them (e.g. do users manage their application status on this app or is that an example of where the product ends?).
There’s so much more work to come: empty states, errors and dead ends, onboarding, edge cases…