TechEase: Accessible tech training — a UX Case Study
This is a case study and reflection of a four-week team design challenge.
THE TEAM
Anita English, Simon Harmon, and Jesse Hunter
MY ROLE
Research — conducted in-person interviews and crafted survey questions
Analysis — generated a persona based on the interview and survey results
Design — low-fidelity wireframes; color theory, typography
Prototype — creating a flow by linking screens with InVision
Testing — usability testing with high-fidelity wireframes
THE PROJECT
Are technological advances leaving people unemployed? Do lower income employees have the opportunity to advance into a career in technology?
At our hands was a social design challenge based on the rapidly-changing technological landscape and standards for entry-level work. This directed us towards thinking about lower income employees, such as those who work in retail and grocery stores, who are generally between 17 and 25 years old. We needed to design a product/service that would offer more opportunities to this demographic of workers.
THE PROCESS
We took inspiration from the Five Planes of UX, which originated from “The Elements of User Experience,” written by Jesse James Garrett.
STRATEGY
In order to create the best online tech learning experience, we had to gather information based around potential users’ interest levels and their preconceived notions of the tech field. Understanding the parameters surrounding any project is crucial to good design.
To assist with formulating interview questions we wanted to pose to current and potential users, we began by writing down everything we each thought we knew about online technical training (e-learning). We included personal experiences with Codecademy and Duolingo.
A sampling of questions we asked:
- What kinds of devices did you grow up with?
- What are things you like to do when you’re not working?
- Have you considered a tech job — why or why not?
Then, after conducting some online research about tech jobs and lower income employment (or unemployment), we were able to organize our assumptions.
Assumptions:
- People need advanced education in math and science
- People don’t really have time to learn tech
- People believe tech jobs to be very boring
We attempted to validate our assumptions by conducting in-person interviews. As a team, we went to the mall and found three retail employees. Taking turns being the interviewer, observer, and note-taker, we started by asking them general questions such as age, education, and occupational history. Then we asked more specific questions about their thoughts about technology and what they envisioned for their career paths.
Some common responses we got from them:
- “I work primarily to get the bills paid.”
- “When I hear ‘tech,’ I think programming, IT help, the internet.”
- “I’m not good at math or science” or “I’m not smart enough.”
- “Tech jobs are lonely — I imagine a computer in a small, dark room.”
Our first speed bump was thinking we could only talk to 19 year olds or those still in their mid-twenties, not really planning on higher education. Because we believed that we could only speak to potential users in this age group, we realized that we had unfairly limited ourselves when it came to getting more interviews. With this earth-shattering revelation, we conducted additional interviews to include wider range of ages and varying educational experiences.
SCOPE
The next step was to analyze the responses and consolidate them in a way that we could craft a persona. This was important because it kept us on track when it came to design and features. We learned it was so easy (too easy) to stray from the overall goals of our project.
We generated a persona based on the interviews and survey results. The first one, we’ll call “Trent.” Trent is a young person, working at the local grocery store, who would like to do more than living from paycheck to paycheck. As you can see, Trent’s an attractive guy but feels embarrassed telling his dates about where he works.
When we found ourselves in this creative hole, we’d go back to the persona (refocus on what the persona wanted).
STRUCTURE
To help us determine what the project would look like, we assumed the role of our persona and established our goals and tasks. We quickly learned that there were many little steps in-between that we’d just… glossed over. The story mapping process really made us consider the flow of actions, which would then inform our design.
Events (a.k.a. “Narrative”)
- View available courses
- View progress of completion (per lesson)
- Get support — ask for help from other users, instructors
- Review the lesson(s) and take an assessment
- Find tech-industry employment
We stress-tested our flow by reviewing each piece of the narrative in the context of “As a [user type], I want to [action] so that [goal].” This was significantly more challenging than I’d anticipated because this was my first time generating a storyboard or user story map.
From these, we decided on the most critical tasks so that we could begin designing a minimal viable product (MVP). Our pictures cut off the steps that fell below the line, but some things we saved for a second version were:
- View paid course bundles
- Find and apply — internally — to job postings
- Viewing and messaging other users taking the same course (“virtual classroom”)
It was important to us that the user could see his or her progress through a course, be assessed for it, and ask for help.
SKELETON
Here are some decisions we made as a result of the user story map.
Main Features
- Auto-Save
- Progress Bar of Completion
- Review Course Catalog
- Messaging Forum
- Lesson Summary and Test
We focused on having an “auto-save” feature, so as to relieve any stress that came to our persona if he had to up and leave for work mid-lesson. The incorporation of the progress bar allowed users to see how much they had done or had yet to do, which we hoped would be more encouraging rather than discouraging. We also wanted to add something of a network despite it not being a full-blown social experience, so the forum would enable users to message each other, ask for help, and offer a sense of camaraderie — if you remember, we had users say they thought tech meant working in solitary. The whole point was to make it convenient and not too sterile that our persona couldn’t enjoy the learning. That’s what made “traditional school” and the thought of more school such a turn-off for our persona.
Now we had to pair our ideas with lines and shapes— visual anchors, so to speak.
I may have gone a bit overboard with drawing out low-fidelity wireframes, but admittedly, this is my favorite part of the UX process. We reached this stage after gathering all our sticky notes and index cards… that had been scribbled on to the point that we were having trouble deciphering what it was we’d decided! I consolidated these annotations into a more cohesive drawing to both confirm the decisions we’d made as a team and provide ourselves more room for comments.
Testing & Iteration
Because I had made these drawings so detailed, it was easy for us to divide the responsibility of converting the screens into Sketch. We kept the design simple with only a few colors, that way we could focus on the flow and information architecture. After this step, we uploaded them into InVision to create a basic prototype.
We approached potential users for feedback on this prototype and provided the following tasks:
- View course catalog
- Take the skills assessment
- Choose a learning path
- Create an account
We also tested to see if users could find certain things like the community forum, where users could ask for help, and where to submit feedback.
In short, our testers responded favorably to the layout and flow. However, one thing we noticed was that some testers had a hard time knowing where to look first, and what to do. From this we learned we had not provided sufficient visual hierarchy to emphasize what our main tasks were.
Some things that we changed right away were:
- Bigger call-to-action and header
- Split the course content into two paths, “Code” and “Design”
- Added more affordances to the tutorial sections so that users could expand, collapse, or exit tutorials
- Added placeholder text to the log-in/sign-up
- Changed the Skills Assessment to an Interest Survey
We tested again after making these changes and learned that we were on the right track with our iterations.
SURFACE
As we moved towards converting the low-fidelity wireframes into high-fidelity (adding copy and images), we really struggled with consistency. You name it — the size and placement of the logo, what links were in the top navigation, the very fonts we were using. This exposed a mistake we had made, and that was proceeding without a style guide in place.
It’s funny now, looking back, that we didn’t even have a name for our product until this stage of our design. I really liked how “TechEase” sounded like “techies.”
We pushed hard and I’m so proud of how we came together to create the product featured below.
CONCLUSION
Lessons Learned
“There are no problems we cannot solve together, and very few that we can solve by ourselves.”
Lyndon B. Johnson
As with any team project, there are frustrations. There’s the risk of miscommunicating something one thought was universally understood — for example, the shade of orange we were using for buttons and accent. There was coordinating schedules to meet over the weekend, and occasionally working late into the evening. There’s the struggle to maintain consistency across versions of the same files. Hey, at least I got really well-acquainted with my new computer, really fast.
A personal hurdle was avoiding the “I’ll just do it myself” mentality. I considered myself pretty experienced with interviewing and using design software, and so, had wanted my teammates to each get experience interviewing strangers as well as creating visuals.
Going Forward
Though it may seem redundant, I want to make sure to outline our goals and the process from the beginning and periodically sit down to review them. The importance of keeping everyone on the same page has never been made more clear to me than when we’re working on different pages (of the product).
We went about the majority of our project time believing that if we were a business, we could keep it completely free. However, it occurred to us time and time again that who would want to shoulder the cost to develop a website and not generate revenue (even for site maintenance)?! In our designs, we had wanted to offer paid course bundles, but settled on offering a few lessons per course, or perhaps a few courses per category for free, and then suggest the bundle or subscription to other features hiding behind a paywall.
Thanks for reading! If you’d like to see more, please visit my portfolio at medium.com/anitaenglish.
