Process: Goal-Directed Design

For the purpose of our application, the whole creating process was driven by Goal-Directed Design (GDD), a design process created by Alan Cooper. GDD is a design process focused on understanding the user’s behaviors, goals, needs and motivations. When creating TAP, we followed the GDD method by the following five phases of the process: Research, Modeling, Requirements, Framework and Refinement.

After our research period, our team transitioned to modeling who our users were to help give us more specific goals for the different types of users we'd have in our app. This helped us in the requirements phase as this gave us more accurate needs of our userbase. Lastly, we designed our first prototype and then tested it with our fellow classmates to help refine the design.

Research Phase

The first phase of GDD begins with the research phase. This phase is important to the GDD because during the research phase it is about information gathering on field competitors, stakeholder’s needs and the potential user’s behaviors and goals. This is where we also established primary objectives of our application.

The Research phase is a critical foundation of Goal-Directed Design in developing the smartwatch app as it provides our team important data and reasoning behind our design decisions. We continuously return to our data findings as consist qualitative data about who our potential users are for the product domain. The research phase is broken down to by the following deliverables: the Kick-off meeting, Literature Review, Competitive Audit, and User Interviews. Each of these process helps our team move forward in developing Kibi and visualize how it would function to meet the user's needs and goals.

Kickoff Meeting

To begin with our research, we conducted a kick-off meeting designed to get the team to set up the foundation of the project goals and purposes.

A kick-off meeting is one of the first meetings as a design team would have with stakeholders. This meeting is where we, as a team can set up general concept and project goals with stakeholders. During this phase, the designers have opportunities to ask stakeholders initial key questions and expectations they may have on the project.

Since this project was being completed within an university courses, we did not have actual stakeholders that would in most cases be present in a traditional kick-off meeting setting to discuss the primary goals of a project. Therefore, we constructed our own problem statement and assumption statement about our potential users.

As a team, we decided that:

• Since the smartwatch interface is going to be small, the whole layout should have simple and minimalistic interface.
• Some quick access provided in the application interface.
• The user mostly are using the smartwatch to remote control their electric car.

Literature Review

After the kick-off meeting, our team started researching about the domain as well as user behaviors and attitudes toward our application. Our main goal during this phase was to get as much information as we could about the motivations and frustrations when sharing and hunting artwork online. This phase is essential because it is important to obtain any prior knowledge on the domain of our application, competitors in the fields, and our users’ behaviors/goals, the literature review gives the latest information in the field by mapping the progress of knowledge.

Our tram gathered statistics on the status of the car remote market, smartwatch devices and their functionality, and existing applications by leading manufactures in he car industry as our application will be universal and compatible with any brand of car.

We found few articles that correlate with the application and its goals. One document we analyzed was a statistical table on the brands dominating the smartwatch market and it influenced our choice in designing the initial app for Apple and IOS smartwatches. Another article featured information on competitors and from this we were able to determine that our app will be compatible with various cars manufactured around 2015 and later.

Competitive Audit

The competitive audit is used to compare existing versions, prototypes, or competitors of a product. This section of GDD will allow our team to understand what makes other social media platforms different from others by examining the features they offer and the capabilities they have. This involved comparing our top competitors to determine gaps in the market that our product could address. By analyzing these applications, we found how our application could stand out in the market.

Competitive audit chart based on the features of each application

We focused our competitive audit on three major competitors: Viper SmartStart, OnStar Remote Link, and MoboKey. While the Viper smartwatch has unique features such as providing car status, parking location, among other features, its major downfall requires a separate device in order to connect to a car. In addition, it requires a subscription in order to utilize the car control. While OnStar provides personalization and a point reward system, its major fallback is the lack of a universal application and a required plan with the temperature control feature. Lastly, MoboKey is a smartphone app that allow users to control multiple cars, provide parking location, and share key option. However, the smartphone app does not come with a smartwatch that can be controlled from your smartwatch.

Stakeholder Interviews

After research about the domain and product but before user research, a design team must meet with stakeholders again to reaffirm their business goals. Some information to gather in a stakeholder interview that they could not discuss in the kickoff meeting would be product vision, budget, schedule, technical restraints, business goals, and the perception of users.

Since this project is a university class project, we did not have any real stakeholders to interview. Instead, we imagined what a stakeholder might have discussed with our team about the application. They would reaffirm that they want to make an application that is easy to use and can connect many people together. However, they would also be concerned with how to reach the application’s domain and how to earn revenue from the services provided by the application.

User Interviews

The final step of GDD’s research stage concludes with conducting user interviews. To begin our user research and learn what goals, behaviors, and attitudes real life users had our team conducted user interview sessions. The first step of this process was to create a heavy focus on the persona hypothesis, information from previous literature reviews along with our competitive audit.

We conducted five user interviews that are all held through a virtual meeting to prevent the spread of the COVID-19 pandemic. We then synthesized our notes on Miro to create affinity maps for each interviewee based on the common topics, ideas or features that was constantly mentioned in our interviews.

Affinity maps serve as a visual representation of user problems and needs. By layering and grouping the data collected during each interview, this will be come the basis for subsequent for the team to define the user needs.

The modeling phase is often based on the analysis of target behaviors and workflow patterns found in fieldwork and interview results and synthesized in a user model. This mainly includes observation and situational interviews to obtain qualitative data on the potential users of the product.

Affinity maps for each interviewee to showcase common topics

Modeling Phase

The modeling phase is important within the GDD process because it helps us to visualize the relationships of our target users for this specific research. Thus, after completing our research phase, our team was able to create two different types of personas based on the research data we collected during the previous phase.

A persona is a descriptive model that is based on the goals and behaviors of real users. The purpose of creating a persona is to minimize subjective assumptions and understand what users really need so that we know how to better serve different types of users.

Behavior Variable Map

Once we have identified all the common behaviors and patterns, we began to look for the most common characteristics among the six interviewees. After identifying them, we are ready to start the requirements phase where we identify the main feature to incorporate into our prototype based on the data we collected from usability testing.

Meet Our Personas

Based on the research results and the affinity mapping, we ended up with two types of personas.

Primary Persona: Matthew Williams

Secondary Persona: Jada Richardson

Requirement Phase

The requirement phase is essential within the GDD process because this phase is where we find out the connections of our developed primary persona, Skye, between the design’s frameworks. How it would help our persona achieve her goals, behaviors, and needs.

To identify the potential steps from our persona would take to reach their goals, we constructed context scenarios that help achieve the goals, behaviors, and needs of our developed personas, when potentially using the application.

The main focus of context scenarios is generating a story based on the persona’s interaction with the application, to address how the application fits into her daily routine and how it helps to meet her goals.

Based from the context scenarios, we also created a list of requirements that helps to allow the user to successfully meet their goals.

Some of the key features we obtained based on the usability testing sessions:

• Quick Access Controls screen
• Fast access to music player
• Car location sharing
• Simple and intuitive interface
• Swipe feature as opposed to back buttons
• Personalized car visual in menu

Framework Phase

In this phase, we transitioned user goals and requirements into visualization. Our goal during the framework phase was to create a low-fidelity wireframe that follows the key path scenarios and focuses on flows and the placement of the elements. Low fidelity wireframes are meant to be quick; it gives a possible layout idea of how the application would look and function. This task was completed using wireframing tools and elements that are provided on Miro.

Below is the low-fidelity wireframe that we created using the key path, the alternative scenario that the primary persona will take through an application to accomplish their goals and validation scenarios, and many other possible paths and experiences within the application we still need to consider for primary or secondary personas.

Building the wireframe

Our team developed the wireframe using the context scenarios, validation scenarios, and main requirements from previous phase of GDD. To begin, we built the key path scenario, which is a path that our primary persona, Mathew, will most often take on a daily basis.. The key path scenario helps determine whether our persona can navigate through each function efficiently without existing the app. This also helps our team identify any missing features that the smartwatch may lack in meeting the user's goals. Once we have built our key path scenarios, we began to build the validation scenarios which are paths that users take less frequently. The image below depicts both the key path and validation scenarios.

Wireframe and low-fidelity prototype based on the requirements

Refinement Phase

Once we completed our low-fidelity wireframes on Miro, we continued using the same key path and validation scenarios while constructing a refinable prototype on Figma. During the presentable stage of designing, we conducted two usability testing interviews with previous interviewees. In the testing sessions, we gave the interviewees simple tasks and monitored them navigating through the application to see if they were able to complete the tasks smoothly.

After conducting the usability testing sessions, we further collected additional data from our interviewees on their thought process and attitudes about the smartwatch overall design. Through this, we were able to walk away with insightful information on the functionality of the smartwatch app which helps our team to develop better solutions in order to meet the user's goals.

Our key findings from the usability testing sessions:

We proceeded to refine our prototype based on the user feedback we fixed the function flows, ensured that the flows are consistent, improved the screen alignment, and removed some elements to make the screen less crammed.

Our Final Prototype

Conclusion

Since we have worked mostly with mobile application interfaces and none of us had designed for a smartwatch before; therefore this was an especially challenging design to tackle. We are proud of how the final product turned out but unfortunately due to time constraints some of the requirements we had listed before were unable to be added to the prototype.

I am so proud of the work my team and I accomplished over the course of two-three months. Having no little-to-no prior experience with designing a smartwatch application, I believe we were successful in what we set out to do.
‍
After completing our project, I've already noticed things I'd like to change. For instance, rather than only dark mode provided to the user, I think it would be better if the user have the option to change their whole layout. I think that would boost the overall flow significantly. Putting the Goal-Directed Design process to practice gave me confidence in my desire to be a UI/UX Designer. I'm now sure that this is where I want to be; this is what I'm passionate about.