Process
A1 Research Findings
Week 2
The following is a list of basic web research that our team conducted. In order to generate ideas and to get a sense for the different kinds of programs that are currently out there, we researched various applications that shared similarities with our initial idea. This allowed us to understand the pros and cons of each type of application and various types of techniques that are used to solve the problem. This step also aided us in the creation of personas, which is the next step, because it generated a list of sources to use as basic secondary user research.
P2 Polished Personas
Week 3
The following are different personas created during the design process. The personas act as a way to identify who the end users will be and how they will use the end product. They are generated based on the web research that we each conducted beforehand, and applied towards different user scenarios and storyboards that we created afterwards. The personas Emily and Dan appears throughout the scenarios and storyboards which eventually shaped the interaction between the product and the user.
A2 Scenarios
Week 4
The following is a list of user expectations and scenarios. The user expectations captures different features and functionalities of the end product that the end user expects. Each of the expectations are followed by a source at which we found the supporting evidence. The scenarios are generated based on the different personas that we created previously. It attempts to illustrate a case at which the end product is useful for the user, while at the same time, refining some of the end-product interactions.
P3 Group Design Sketches
Week 5
Seen below are the design sketches our team created in order to depict the various functionalities of our application. What’s important to understand here is that the purpose of the sketches is not to complete the graphic design of our application but instead to come to a general consensus of what our major components are and what their basic design scheme will look like. We started off with a solid understanding of what features we wanted to provide through the user scenarios we had created previously. But with our design sketches, we now give these features a visual representation that is more relatable to the application. However, a key component missing from these sketches is the emotional perspective of our users that gives them the impetus to use our product. This is why we direct our attention next to making storyboards.
A3 Storyboards
Week 6
The purpose of the storyboard in the user centered design process is to tell a story about how our product will be used with a combination of text and image frames. Borrowing this concept from the film-making industry, the ideal design storyboard uses the setting, the sequence of events, and the satisfaction of the characters (which represent our personas) to portray exactly what an application or system has to offer to the target user. In each of the storyboards below, you will see how the main character is able to better interact with and appreciate nature through our application. We also utilize the option to show a toned down version of design sketches within our frames to better portray how the mobile application is used. Overall, at this point in our design process, the product functionalities are defined and justified by user needs. We now need to sort out the details of our application; starting with the information architecture. This is where we start building a sitemap.
P4 Sitemap
Week 6
The sitemap as depicted is meant to help with the information architecture of our application. We created the sitemap as a roadmap to identify our high-level pages and sub-pages and help with organization. Based off of the group sketches we previously made, we were able to identify the main features of our application which translated to the high-level pages. From there we were able to dissect each of those main features into sub-pages that the user would encounter when using a main feature. Once we had the sitemap we had a clear direction for what our application would do and what screens the user would need to encounter to use the main features. The next step was to create a paper prototype that would be based off of the sitemap. Since the sitemap identified each screen that the user would encounter it provided a clear roadmap for the screens we had to prototype.
P5 Paper Prototype
Week 7
The paper prototype we made included our four main features: Plan, Identify, Collection, and Game. Instead of communicating ideas as with the sitemap and those before it; the paper prototype was made with the intent to be user tested, so it is made to resemble what the real application would appear like. Based off of the sitemap we previously made, we were able to create a screen for every level of the sitemap covering all four of our main features. The next step once we completed the paper prototype was to run a usability study on it. Usually we would have ran a full usability test, but due to time constraints we had to cut it down to a basic usability test on two users.
P6 Paper Prototype Quick Evaluation
Week 8
After completing the paper prototype the next step normally would be to conduct a full usability test. However, due to time constraints we had to create a simple evaluation plan and run a simple usability test on two users. Running a usability study is helpful in the design process since it gives us feedback about our prototype on how we can improve the user experience of our application. For this usability study we did a quick evaluation of our paper prototype which was comprised of our four main features. Based off of the quick evaluation we gained valuable insight about our application which we then used to design wireframes.
We printed out our wireframes and posted them around the classroom for a critique.
P7 Annotated Wireframes
Week 9
After developing our paper prototypes and working with potential users to discover more about the potential functionality of the application, we were able to finalize many of the features and move on to developing annotated wireframes. For this portion of the project we focused on the creation of mockups that were of a higher fidelity than the paper prototypes and were representative of a version that was closer to finalization. These annotated wireframes mapped the majority of features we hoped to include and also included annotations that were used to explain functionality. The goal of this was to create an artifact to show to potential stakeholders as representative of the overall design and functionality we planned to develop for our application while simultaneously acting as a precursor to our high fidelity mockups.
P8 Hi-Fi Mockup
Week 10
After receiving useful critiques on our annotated wireframes we developed a few high fidelity mockups to convey the visual language and style of the application as well as presenting what the final product will look like. This served as a sort of final step of our process before we had something that we could show to a development team for the application. When working on our high fidelity mockups we were able to incorporate feedback from wireframes as well as come up with a style that would match the preferences of our previously developed personas.