Add a Feature Challenge
Kate Lexner|Ironhack FT UIUX Bootcamp|Week #4| Individual Project
As I entered into the 4th week of my UIX bootcamp experience, we were given the opportunity for our first individual project. During this project, my goal was to analyze an already existing and highly utilized app, and incorporate a new feature into its current state. The feature I was to develop was to be based on user input, that I would obtain by implementing the double diamond method, design thinking as aspects of agile methodology. With that being said, my mind immediately jumped to Uber for a multitude of reasons. With Uber being as popular as it is, I knew many individuals who consistently using the app which would expose me to a genuine view of what users actually think when using the Uber app. I was also lucky, due to the fact I had obtained some Uber research during my pre-work days, since Uber was an indirect competitor of Citymapper, an app I was asked to re-design before bootcamp begun. So by having a basic idea and some background knowledge regarding Uber, and the knowledge I would gain by Empathising, Defining, Ideating & Developing that would eventually lead me to creating & implementing the RideVibe feature.
— Secondary Research
As the first phase in our process, my main goal is to empathise & discover information that I would be obtaining data through in-depth research. The first type of research I would jump into, would be Secondary research, in order to gain as much insight & understanding of the entire Uber experience.
I started by familiarising myself with the basic background information of Uber, like it’s headquarters being located in San Fransisco CA, or how, even though Uber was created in 2009, the ride-sharing market has been around since the early 2000s, the idea coming to conception in Europe. More importantly, I would determine the total number of riders, as well as the overall revenue earned between 2016–2020, which has consistently been in the red almost even year, and I was even able to determine WHY that was the case. This information obviously would be beneficial long-term because it proves, that Uber is definately in need of bringing in more revenue & needs to create something new to do that.
— UX Strategy
After I felt I had obtained enough Secondary Research, I jumped into the next aspect of research, the Business Analysis. I decided I would begin by utilizing the UX Strategy Blueprint. UX Strategy is a way of uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome. … the main theme being: if we do this, then we expect to see that. It helped me lay out a strategy of how I was to identify the ultimate solution for Uber users. The eventual takeaway would lead me to the general understanding of the challenge, the goal I wish to attain with my feature, the eventual main focus areas my feature would target, & what I wanted the guided theme of my feature to be, & finally how I would measure the success of the failure of the feature.
— Competitive Feature Comparison:
The next step in our Business Analysis is our competitive feature comparison. What this allows me to do is determine potential market gaps, while taking Ubers biggest competitors & holding them to the same standards as Uber. Not only does this help me identify the current gaps in the market, but in a coherent & organized manner that will be easy to refer back to throughout my process. For my own personal Competitive Feature Comparison, I chose LYFT, BLABLACAR, VIA, & HiTCH as Ubers direct competitors. I would determine the current availability to the public, it’s conception year, how much it may cost, as well as the variety of features each app offered. As predicted, LYFT was the most similar to the overall experience Uber has to offer. I determined that even though “VIA’s” overall focus was on utilizing all public transport, & affordability, compared to the its competitors, in this comparison, VIA was the most affordable & economically smart choice. What I learned about BLABLACAR would be somewhat influential in what would be my eventual end product. The primary focus of its features was the fact the drivers were the ones in control & the users were able to catch a ride basically if they were heading the same way… more so, a pre-determining indicator of whether the driver cares to interact with the rider or simply drive. Lastly I learned the interesting take HiTCH has taken on the “carpool” aspect of ridesharing, by being a bus service whose only routes were college campuses. Though HiTCH’s biggest downfall is its lack of avaibility & only being available in Texas. Using the wide range of information I obtained while researching Ubers direct competitors, as well as my initial secondary research, I was heading into the next aspect of my process with the data to back it up.
— Market Positioning Chart & Blue Ocean:
A market Positioning Chart is crucial when it comes to creating our eventual marketing strategy, and helps me understand & influence consumers perception of the feature. Along with utilizing the market positioning chart, is the blue ocean strategy. The blue ocean strategy is beneficial due to the fact it lead me to determining an opening in the market based off where the direct competitors lay, & create an entirely new market space with our feature. Essentially the overall goal is for capturing an uncontested aspect of the current market, that renders the rest of the current competition irrelevant. First I established where Uber would fall on my chart, considering the variables of cost to no cost, & the variety of feature options to the bare minimum of feature options. With that in mind, I would then chart the direct competitors from my feature comparison, & from there determine my blue ocean. In this particular instance, my blue ocean would lead me to create a feature that, adds variety to the type of offerings, with no additional cost. Now that I knew the guidelines of my future feature, I would jump from my business analysis, and begin the last phase of my research which leads us to User Research.
Being the last step in our overall initial Discover phase, in my process, I began my User Research. My main form of going about this was by obtaining as much Quantitative & Qualitative data as possible without losing track of my limited time frame of 5 days. Though this is a process I have kept in mind since beginning the overall process.
— Quantitative Data
The benefit that comes from Quantitative Data is the broad range of perspectives it offered me through surveys I had created. This particular aspect of user research is more concerned with the “What” as well as the overall quantity of data we are able to obtain. In my particular circumstance, I would have 20 people who would take my survey, giving me 20 different perspectives regarding Uber. The most informative information I would take away from my surveys would be that 80% of users main use of Uber was while under the influence. Also, roughly 90% of my survey takers would reveal that they absolutely believe that Uber is necessary, yet 66% of those people admitted that they are inconsistent with their usage of Uber. As this information starting coming in, I was beginning to have an understanding regarding the types of questions I would ask during my interviews.
— Qualitative Data
As I let my surveys gain perspectives in bulk, & gain insight into the reasons why users are using Uber, I began the process of interviewing individuals I knew, who had much experience utilizing the Uber app. Qualitative Data is the “Why” data, a detailed account of an actual user of the uber app. This data is so beneficial because not only are you gaining first hand knowledge of the pains users of the app had endured, but also because it helps us to really empathise with the users overall experience & potential needs. I managed to interview 5 people, by getting 2 couples interviews. What was a theme I noticed quickly amongst the women was the concern they had regarding the current safety features that Uber was offering, while the men’s biggest concerns were more focused on time accuracy & overall ride experience wanting to avoid any type of awkward of unnecessary situation. A few quotes I would take away from my interviews were both along the lines of wanting to avoid any awkwardness, or potential issue during the actual ride itself.
— Affinity Map
As I began organizing & synthesizing all the data I had obtained up to that point, I was able to start noticing a theme…. specifically with the Uber riders who didn’t live in a metro area & and a different idea of how Uber was beneficial to them, opposed to someone who doesn’t own a car & heavily relies on ridesharing apps as their primary form of transportation. I took all the data I had gained, regardless how relevant it would end up being to the eventual feature created, & organized it into the following catergories… “Why the used Uber,” “When they used Uber,” “Transport & Features they used most,” “Clear Negatives regarding ridesharing,” “Clear Positives regarding ridesharing,” “Direct Quotes” & “Emotions & Thoughts throughout ridesharing experience.” Now that this information was in a clear and organized in a coherent manner, I was able to easily refer back to it throughout the rest of the process in order to make sure I am staying on track of creating something that is clearly backed up by the data I had obtained.
— Value Proposition Map Customer Profile:
After I completed my Affinity Map, the next step I would take was filling out a Value Proposition Map Customer Profile.. The Value Proposition Map is a visual tool that let me plan what problems or desires my feature would address, in a way that allows you to find a match between your product and the expectations of your customers that I determined throughout my Discover phase. With my Customer Profile, I was able to determine that the problems & desires my feature would try to address would be based off: 1.) “Awkward rides being made to be more enjoyable can result in more consistent use of the Uber app when customers need to get somewhere,” 2.)“Riders who feel less safe, can be made to feel more comfortable and reassured when users are utilising the ride-share service,” & 3.) “limit the number of bad experience for BOTH Drivers & Riders.” With now having a basic understanding on what the main focus my feature would address, I am able to create an accurate As-is scenario, which would be the next step within the Define phase of my process.
— As-is Scenario
The As-is scenario was incorporated into my process because they help to document collective understanding of a users current step by step workflows within the present confines of the app & help indicate which areas could use some improving upon in order for users to have a better all around experience. All this by breaking down a step by step re-enactment of what the task is and how it made them think feel & notice while experiencing it.
The steps I broke down my process would be, 1.) Choose Transport Method, 2.) Input Rider Request[When&Where], 3.) Confirm Ride, 4.) Wait for Ride & lastly 5.) Endure the actual Ride. I then took the information I had gained from my Qualitative & Quantitative Data, as well as Reviews of the Uber app and incorporated it into my As-is scenario indicating even more clearly, what Uber customers low points were, as well as the type of feature I would eventually create.
— User Journey Map:
The next step I would implement was a User Journey Map. I did this because of the visual representation of the customer experience it offered to me in an obvious & clear manner, by being able to easily identify with the user’s point of view, understand and determine their low points in the experience based on the data gained so far, and is a crucial step when creating a feature that is genuinely based on the low points of Uber customers experiences once that experience is broken down. I kept the same 5 initial steps in the process, with the addition of the users overall journey up until their actual arrival at the destination. The three low points I determined from my User Journey Map would be the 1.)Inputing of Specific Ride Details, 2.) Waiting longer than initially expected & 3.) Enduring the ride itself.
— Problem Statements:
At this point, I felt I was in a position to finally determine my 3 Problem statements. The UXplanet describes problem statements as the following; “A problem statement is a clear description of the issue (problem) which also includes a vision and methods used to make ways into solving the problem. Basically, it’s a clear, concise description of the issues that need to be addressed and it is used to center and focus the team, (in this case, myself) at the very beginning to stay on track.” My 3 problem statements would end up focusing on both Riders & Drivers, as my overall goal deep down is to create a feature that genuinely benefits everyone involved in the process, and as I came to define my problem statements, is when I begin to feel that I could potentially act on & reach that lofty goal.
— How Might We Statements:
From my problem statements, I am able to determine my “How Might We” statements. The reason for incorporating this aspect within my Define phase is because it is helpful in guiding me in the upcoming Ideation phase and ensures that the focus of my brainstorming is based off of the problem statements, just in a re-worked framework.
I’ve finally reached the aspect within my process in which I felt I was able to start brainstorming potential ideas for the feature I would add to Uber. By taking the information gained throughout the Discover phase, the organization & prioritizing of the data & being able to accurately determine the low points throughout the current Uber experience during the Define stage, and determining my 3 problem statements & How might we statements, gave me a solid idea of the types of ideas I would come up with. I came up with roughly 18 potential feature ideas, ranging from safety, to accuracy all the way to creating an ideal ride experience. I attempted to come up with atleast one idea for every issue I would discover throughout my previous steps, & once I felt I had done that, I felt ready to start deciding what my feature needed to have in order to meet the needs of Uber users & create something that they would find beneficial & enticing.
— MoSCoW Method
The benefit the MoSCoW Method brings to my overall goal of creating a feature based of what users want is high & extremely informative. Im someone who seems to thrive during the ideation phase & come up with a wide variety of feature options, whether its something basic or innovative. The downfall of that can sometimes be, its hard to prioritize what to actually include in the feature.. This is why the MoSCoW method is so helpful. It literally breaks down all my ideation into 4 seperate areas.. “Must Haves,” “Should Haves,” “Could Haves,” & “Wont Haves.” This makes it easy to determine what needs to be in the feature I create in order to hit the specific pain points I have determined and from their, begin creating my feature. I was able to determine that — A PRE WARNING FOR DRIVERS — AMBIANCE TARGETED -PERSONALISED PLAYLIST -ENERGY STATUS INDICATORS -CONVERSATION STATUS -CAR VIBES is what would influence by eventual feature.
— Value Proposition Canvas:
Broken down into the following catergories, “PRODUCTS & SERVICES WITHIN MY FEATURE,” “PAIN RELIEVERS, & THE ASPECTS THAT CURRENTLY SOLVES THE PAINS OF THE UBER USERS” & lastly the CREATOR GAINS & THE ASPECTS THAT WILL BENEFIT THE CURRENT UBER APP & IMPROVES ON THE USERS EXPERIENCE. Within these sections, my feature starts to come together, quite literally. I decided my focus would be on the overall rider experience & attempt to create a feature that not only helps riders feel comfortable in their current circumstance, it also allows drivers to feel prepared due to being informed to the type of riders they would endure. This would offer not just ideal customer service since the ride is adjusting to the literal riders needs, but because it involves the drivers as well, which hits both types of Uber “users.”
The Neilson Group defines Jobs2bdone as follows, “a framework based on the idea that whenever users “hire” (i.e., use) a product (feature), they do it for a specific “job” (i.e., to achieve a particular outcome). The set of “jobs” for the product amounts to a comprehensive list of user needs. In this case, it helped me to specifically correlate what needs my feature is to meet on broad basis, and how we intend for it to work & make our users feel. I would create my Jobs2bDone by following the framework of,
“WHEN (situation), USER WANTS TO (motivation), SO THEY CAN(Expected Outcome), WHICH MAKES THEM FEEL ________..”
— RideVibe MVP:
Within my very limited 5 day timeframe, I came up with the concept of the “RideVibe” as my MVP, also known as the Minimum Viable Product. Though, I would initially dabble in a safety inspired MVP, after reflecting back to previous aspects of my research, it became clear, that would be unnecessary & guide me towards creating an MVP that targeted a very subjective aspect of the actual car-ride itself. That being said, my MVP is not supposed to be the final iteration of my feature, but a feature with just enough that targets the current pain points & considered to have improved upon them in the most minimal fashion, which is where the idea for the RideVibe came from. The pitch I came up with goes as follows:
“ UBER NOW ALLOWS ITS USERS TO INDICATE THERE CURRENT ENERGY LEVELS/ MOOD LEVELS/ &DESIRED INTERACTION LEVELS AS WELL AS HAVE THE OPPORTUNITY TO CREATE AND PLAY YOUR UBER PLAYLIST. WHETHER ITS TO EITHER KEEP THE PARTY GOING, OR SET THE VIBES FOR A CHILL NIGHT, THE INEVITABLE CRASH THAT SEEMS TO BE INEVITABLE BETWEEN THE PREGAME & ACTUALLY GOING OUT IF THE CIRCUMSTANCES ARE NOT JUST RIGHT.. RIDEVIBE NOW SOLVES THAT ISSUE NOT JUST PREPARING DRIVERS AND GIVING THEM THE OPTION TO TAKE THAT RIDE, AND AS FOR RIDERS, FITS THE NEEDS OF THEM IN THAT CURRENT MOMENT WITHOUT FEELING AWKWARD OR RUDE! ”
— Lo-fi Prototype
Before I finished all the aspects of my very own design-diamond-agile multi-method process, I had initially formed the assumption that my feature would be influenced & focused on the safety issues surrounding Uber. This assumption stemmed from the fact that since a little less than half of the Qualitative data I would obtain would be from women, & safety was the consistent theme I had noticed during interviews. Though it wasn’t the predominant pain point due to the fact not one of the men interviewed determined the lack of satefy options as a low point for them, it still was one of the more consistent negatives mentioned, most likely due to the small interview pool of 5 & the minimal time I had to come up with a concept & functional MVP. It was also the one most easily empathised with pain points, especially as a woman. I quickly realized, I needed more specific information, regarding what Uber was offering at the current moment & quickly noticed just how much the pandemic had kept Uber users out of the loop. Its quite clear that during the time in which apps like Uber were rendered useless due to the lockdown that resulted from covid-19, the stakeholders at Uber took advantage & decided they would use it to improve MASSIVELY in the safety department & the features it would offer. I believe these feature implementations were wise and frankly necessary, hence why some of my initial lo-fi sketches revolved around a walkie-talkie safety feature. Once I had the safety idea out of my head, was when I was finally able to come up with my RideVibe idea. Not only did I enjoy the fact that this feature was enticing, fun & focused on having an ideal, positive experience of the ride itself, but it was also quite different, than all Uber’s previous offerings & is a feature that benefits the riders & the drivers, which overall bring immense value to stakeholders. When you have happy employees, that appreciation will often reflect in the service they give, regardless what field.
Once I finished my RideVibe lo-fi & managed to 2 usability tests, from my brother and friend Jeff, I was able to gain some specific insights. First off, the lo-fi was hard to understand and confusing to navigate with the minimal labels & minimal direction according to my brother. Jeff would have a similar opinion, but would determine the benefit for both rider & driver with his minimal understanding which was ideal, but also a 1-off. A suggestion that was given to me after I further explained the overall concept idea was instead of indicating a desired “conversation status” perhaps “interaction status” sounded better, which I would agree with and implement into my eventual hi-fi.. but before creating my hi-fi my next step was to take the insights I had just gained and incorporate them into my med-fi.
— Med-fi Prototype
I found that my Med-fi would end up garnering me more beneficial insights from usability tests. Since my med-fi design allows me to incorporate more aspects of the design & the necessary information needed in order to successfully navigate through the RideVibe Feature successfully. The med-fi usability tests made it clear, that this version was very much easier to understand & navigate. In the opinions of my fellow ux designers, perhaps had too much detail for a med-fi which is advice I would try to remember for every project hence forward. I was also able to determine that the individuals who utilize Uber more as a DD & not as their primary mode of transportation, definately saw the benefits of incorporating the RideVibe, since each of them at one point or another, had personally had a bad experience with a driver, during the ride that had a wide variety of reasons. Also, the playlist feature seems to be very enticing to people, since many share the similar opinion of mine that music can be transcending & beneficial in many types of scenarios, & with a feature whose overall goal is to create the most ideal ride possible, music often helps with that. The reason I continue to incorporate these usability tests isn’t just because the different insights it brings me, but because it helps me maintain a design that is truly based off the needs of the actual Uber users, as well as create a Hi-fi prototype with minimal iterations, yet still manages to improve the current experience Uber is offering.
— HI-FI PROTOTYPES:
As I began the process of creating my Hi-fi prototype of the RideVibe Features, I would come away with some assurances, as well as some constructive criticism. Some of the most beneficial insights I would gain from my initial Hi-fi presentation to the class were, “The concept itself its highly appealing to both current Uber Riders & Drivers, with Uber customers within the class determined that the RIDEVIBE is definately something they would implement the few extra steps for. I also received input from an individual who was a former driver for Uber, who conveyed that just the opportunity for accurate information ahead of approving a ride would be extremely beneficial, as well as ideal. Often times drivers feel they’re needs are often overlooked as the expense of the rider, which they admit directly impacts the service they give. Lastly, and what I felt was some of the most constructive advice regarding creating the ideal feature for Uber was a UI improvement. Regardless how new I am at UI design, I can admit that once I took a step back & really acknowledged the choices I made when designing the RideVibe app, it did not align with the sleek, and minimal design that Uber offers. Once brought to my attention, I agreed that the UI needed to be upgraded due to the cartoonish vibe it gave off, and it didn’t really seamlessly integrate into the current design system.
Keeping in mind the insights I had gained after presenting my RideVibe feature to the class, I decided I would improve upon the UI as soon as I could before having to jump into the next project to follow in the Ironhack bootcamp. With the goal of creating more appropriate design choices, in order to create a more seamless integretion of the feature. I made the decision to keep the offerings of the RideVibe the same, since not only did those in my personal life see the benefit & appeal of the RideVibe feature, but also because after my initial hi-fi presentation, the question was asked: “Would anybody here actually utilized the RibeVibe feature..” & it seemed to be something many of my classmates could see themselves using! Below is the current version in which the RideVibe feature operates.
— Success & Failure Metrics:
I would determine whether the RideVibe app is successful by the following metrics, regarding Customer Satisfaction & Employee Satisfaction, Feature Retention Rate,Task Completion rate & Positive Reviews. With my personal experience within the customer service industry, I can say with confidence that when the employee satisfaction is maintained, so is the high level of customer service being provided. I also said retention would be a success indicator, and I believe that to be true because the RideVibe app shouldn’t be a feature you tried once & forgot about, but instead a crucial step in a night out, or even a chill night in. On the contrary, I would consider the RideVibe app as a failure if drivers continue to provide negative customer service or consistently quitting. Riders are utilizing competing ridesharing apps as well as a consistent amount of negative reviews.
As I come to the end of my Add A Feature challenge, I can say that I truly feel the RideVibe provides numerous benefits to both sides of the Uber experience, by allowing drivers to make informed decisions & for riders to have an ideal riding experience in a setting in which they are comfortable. The playlist feature seemed to be the most popular aspect of the feature with those who I exposed the feature idea too, unanimously agreeing the subtle addition of implementing a playlist helps many feel comfortable in potentially uncomfortable situations. The other key takeaway i’d like to reiterate from previous in my case study was the fact that Uber is viewed differently for those living in a metro area, without a car & rely on Uber as their primary mode of transportation, while on the flipside, people who live in the suburbs, and tend to have their own cars, & rarely rely on any type of public transport, and see Uber more as a designated driver, and its essentially that demographic of people this app seems to target.
— Next Steps:
Lastly, the next steps I intend to take in order to for my RideVibe feature is to again go back and see what UI aspects I am able to improve upon, as well as more visually appealing. Potentially in the future, I’d like the create an aspect of the RibeVibe in which riders are able to add other Uber RibeVibe users to their current ride and have access to their created playlists. Finally, after implementing the RideVibe in its current state, I’d be able to gain a more clear idea of what else Uber users can do within the feature, or what can be better.