COGS 187A — Team Terminal: The Beginning

TeamTerminal
COGS 187A Summer 2016
20 min readAug 8, 2016

Updated by Johnny Chau

Hello everyone! Welcome to our world, we are Team Terminal.

We’ll start off by diving right into our logo design process. Each member of our group came up with a creative logo to represent us as a whole. Take a look below to see for yourself!

As you can see, some of these logos have elements of music mixed in it. Our group has a strong interest in creating a website that fulfills a need that revolves around music. Simply put, we all love music and want to create a better music experience for people. Additionally, we named ourselves Terminal because the majority of us are Computer Science majors. We wanted a team name with a logo that represents us as individuals. Everyone created multiple sketches of potential logos before deciding on the polished logos that you see above. The process of selecting a logo for our team is still ongoing and we’ll announce our decision soon!

Before we go any further, let’s meet the team.

Members: Johnny Chau, Soo Chu, Wendy Vivar, Sing Xiao, Erik Brown, John Shin.

These are the beautiful faces behind the names. Stick around to see the awesome website we are building!

Stage 2: Brainstorming the Idea

By Wendy Vivar

Brainstorming for our idea began back during the team logo creation process. Before we could find what we wanted our team logo to be we wanted to figure out what we were coming together to create.

Initially, we veered towards a musically-inclined product and began to brainstorm based off that.

The following session we worked to keep our options open so we each came up with various alternative options and narrowed them down to one study group based application.

It was not until we entered the Needfinding stage that we found that it would be difficult to contact different types of potential users for the music-based idea and so we turned to our study group which felt like something that would be more useful to college students (a demographic that was definitely more accessible).

And so we began the journey towards StudyTerminal by first revamping our logo.

Current Logo Iteration Draft

Stage 3: The Interviews & Needfinding

It was in this stage that we made the shift from one idea to our final one. We broke both ideas down and examined them to find what types of users would be using them. Each person came up with 2 for each that we then combined and broke down into 5–6 major categories for each.

User Categories for StudyTerminal

This helped us realize that it would be difficult to reach out to many of the potential types of users for the music application while the users for the study application were more accessible.

We then each came up with 10 questions to include in our basic interview guide. Once again we combined and narrowed down ideas by each voting on the top 5 ideas we felt would yield the most valuable information. We also tried to incorporate some advice from the IOD@Stanford’s article and use questions that could give us more insight on why our interviewee’s study habits are what they are and if there is a difference between what they say they want or do and what they are actually doing- uncovering latent needs. From this we created a basic 10 question template for the interviews with additional questions that could be asked depending on the type of interviewee.

Interview Guide for StudyTerminal

We each had at least one major user category to cover in our interviews to make sure that we received input from all of our potential types of users. When we met again we discussed each of our interviews by looking at interview answers and trying to find what our interviewees needed, not necessarily looking for solutions right away.

We then looked at these needs and the features currently planned to see how our idea and basic model was addressing (or not addressing) them. By the end, we had created a basic framework of features according to our Needfinding.

A Visual Description for our Computer Science-based Group

Stage 4: Examining the Competition

By Wendy Vivar

In individual research efforts, we could not find any other application or website that already did what we were setting out to do so we broke the idea down into functionalities and found competitors in those aspects. The team also took note of what platforms our interviewees were currently using to find study spaces.

Once we had a list of “competitors”, we assigned two people to each platform- one that had experience using it and one that did not. This helped get an all angles view of how these platforms could be competitions. Both team members examined similarities and shared functionalities between the competitor and StudyTerminal as well its the pros and cons in relation to these similarities.

Potential Competitors included:
Slack
Facebook (and Messenger)
FourSquare
Google Hangouts

In short, we found that competition was either messaging based (such as Facebook Messenger or Slack), event or location based (FourSquare, Facebook), or group-study based (Google Hangouts and various online study sites).

Messaging-Based Platforms were good in that many people are comfortable with their existing messaging platform of choice. Groups are easy to create and delete once done and many already had some sort of study group in their messaging app. However, it is difficult to keep track of shorter, temporary timed events where people are studying. Also, repeated messages regarding arrival at a study location were good when the group agreed to all meet to study but turned to spam in every other case.

Event or Location apps worked well for larger events and gave a centralized discussion page for an event. However, much like the messengers, events and check-ins for smaller study sessions made distinguishing events more difficult and took from the importance of larger events.

Group-study aids such as video conferencing or online study groups seemed to work very well but don’t really address the major needs our application is trying to help which is studying in real time.

Personas and Storyboards

By Sing Chung Xiao

Remarks on Needfinding

I feel that it is important to keep the process of needfeeding ongoing in the background. In the paper, “The Why and How of Uncovering People’s Needs”, by Dev Patnaik and Robert Becker, they briefly mentioned a certain company that used to be around. This company as I remembered it, was very well known for one particular product that was as ubiquitous as Starbucks is now. The company is none other than Kodak and the product being their yellow disposable camera. When Patnaik and Becker lauded Kodak for their use of needfinding to chart their future development, I realized that this article has to be dated. Sure enough, a quick Google search confirmed my suspicion. As far as I know, Kodak went bankrupt because they didn’t think that people would be interested in digital photography even though they had invented it first. This would implied that Kodak either got complacent since they had a stranglehold on the photography industry or they made the costly mistake of underestimating the growth of technology. Though, they are not the only company to fall to obscurity. After all, the tech industries is very volatile with new companies emerging constantly. Dev Patnaik and Robert Becker also made a passing remark regarding Palm which doesn’t seemed to have fared any better than Kodak by 2016.

An Analysis on our Needfinding

If anything, Kodak/Palm success and subsequent demise are great case studies that emphasizing the necessity of needfinding. Obviously, Team Terminal has no interest in becoming into these sort of case studies. Therefore, it is imperative that we pay close attention to the results of our needfinding. The results were quite hopeful as people did like the idea we were pitching and would use such an app if it existed.

Developing our Personas and Storyboards

In the next stage of the design process, we started creating personas based off the results of our needfinding. Each member of the team was tasked to create a persona and three subsequent storyboard for the persona. This is where Mark Baskinger’s article “Pencils Before Pixels A Primer in Hand-Generated Sketching” came in handy. This is evident in our use of pencil and paper for our personas and storyboards. While the tools we used were mostly the same, there are some differences. One of these differences is the medium that we used for our sketches. Most members of the group used a blank white sheet of paper for their medium. Whereas I used lined paper as my medium and Soo used Post-its. As Baskinger remarked “… media used can all vary greatly… There is only one rule when drawing to capture ideas: Each idea must be explored from many different perspectives.” With that in mind our team came up with five unique personas. The undergraduate(gamer), the undergraduate(studious), the graduate, the student athlete and the leader of a student organization. The following images are the personas and one of the storyboard associated with them.

The Student Org Leader and this is his story.
The Athlete and this is his story.
The Gamer and this is his story.
The Graduate Student and this is his story.
The Studious and this is his story.

Initial Prototyping

By John Shin

Sketching out our plan

With our personas and storyboards done, it was time for us to start designing our website. To get a better idea of how our website would function, we began drawing out the main functionalities of our site. We decided that the best approach in prototyping our idea would be to have everybody individually come up with their own design, and try to merge the best parts of each of our designs. And so we came up with the prototypes below.

The result of our individual efforts

Coming Together

When we convened to share our prototypes and discuss our thoughts behind the design of each of our work, we found a common problem in most of our prototypes. The website was just too cluttered and difficult to navigate. We found that in trying to implement all our functionalities, we created too many different pages for the users to navigate to. Things just weren’t very intuitive. After discussing our course of action, our group agreed to use Wendy’s prototype (pictured below) as the skeleton for our final prototype.

Wendy’s prototype

The deciding factor in adopting Wendy’s prototype as our model was the simplicity of it. Instead of having the homepage link the user to multiple different pages, it gave the users a homepage with a couple buttons. The users could use these buttons to activate popups which would guide them in creating or joining different study sessions. We tried to keep simplicity in mind as we designed our group prototype. We kept parts of Wendy’s prototype that we liked, and fleshed out other parts that needed more work.

Our revised prototype

Polishing

It was important to keep the core idea of using popups instead of new pages to reduce clutter. From there, we discussed what functionalities were important to the users and began adding them one by one. We opted to have our site be based around Facebook logins and have our system be based our the friends system. While we contemplated opening up the site to non-Facebook users, we wanted to keep to our theme of simplicity and decided to limit it to Facebook only our first go around. Users would be able to create and join study sessions with their friends using our popup menus. With our revised, slimmed down prototype in hand, we were ready to move on to the next step of the design process.

Insights from user feedback

by Sooyong Chu

Insights from FireMelon

Now that we had a prototype that we can base from, we asked our fellow partner team FireMelon to give us initial feedbacks for our design. Team FireMelon provided positive insights that shaped our design more user friendly and efficient. Team FireMelon generally agreed that there were room for improvement but were fascinated with our initial design and idea. Luis, one of a team members of FireMelon, quoted “The prototype seems to have a good potential”. Kevin, another member from FireMelon commented that our app had a good potential for not only for university campus use but also for a wider community.

Kevin asking about prototype features

Their feedback was valuable because it was the first testing done by someone else other than our team members. It helped us to extend our views on how the design will develop for wider users. Our team did discuss about how our initial prototype may intimidate users with so many things going on one page. the user feedback reinforced our concerns and asked to be redesigned. Many times they asked us what each features did and we had to explain what they did, but they were corporative and patient and showed interest in our prototype layout. After going through their insights, our team were eager to improve our design as we new that the initial prototype had many things to be developed.

User Feedback

General feedback we received was that it was confusing what was going on on our homepage. Because we wanted to have every features to be available in one page, our prototype drawing may have caused confusion. But after explaining what each boxes and pop-ups were doing, they agreed that it would look more clean and simple.

initial prototype drawing with detailed features

Another important feedback was about privacy settings. They liked the feature of showing and hiding user’s location to other users but explained how our design may confuse users. Another important feedback was about how adding friends should be linked to school email, regarding the fact that some users may not use Facebook. Their insights and feedbacks covered things that our team missed or have not thought about when designing our prototype.

Design decisions, based on heuristics and user feedback

by Sooyong Chu

Heuristic Evaluation

With insights and feedbacks we have received, our team discussed on how to improve our design. As we evaluated, first we decided to include features that were necessary in our design that we missed to implement. From visibility of system status, our design was on point except that we forgot to show the profile of current user. For match between system and the real world, we concluded that there was nothing much more we needed to do because our user interface is simple and direct. For user control and freedom, the main issue was that there was no feature that let users to create/destroy session on the main page, which was crucial to our focus and priority of our design. Another point out was made on consistency and standards in that use of buttons/bullets/boxes were inconsistent. Wendy also mentioned that current design my depict unclear difference between leave/end session. For error prevention Johnny and I suggested that some sort of assurance mechanism for leaving/ending session may be required. Also, users will only be able to join one session at a time, thus graying out other sessions when the user is already in a session. For recognition and recall we were concerned that the check in image may be unclear for users, and feedbacks we received today reinforced our concerns. For flexibility and efficiency of use, we concluded that we lack shortcut implementations for more advanced users. For aesthetic and minimalist design all of us agreed that our use of space is not efficient and thus may provoke overwhelming depiction for users. For help and documentation we did not provide any.

Design Decision

Now that we went through heuristic evaluation, we achieved further understanding of how we should develop our design. we considered highly on user feedback from last meeting and discussed how we should make changes. We divided design decision from high importance, middle importance and low importance. For high importance we listed implementing confirmation button, online/offline button, exit conformation pop-up, shortcut to leaving session, sign-up system and tag search bar. For confirmation button we will implement a button to confirm creating or ending a session. for online/offline button we will implement visibility shortcut UI for users. for shortcut to leave session we will add a shortcut next to check-in/check-out button to easily leave a session. for sign up system many ideas came up but we decided to create a signup system for users that do not have a Facebook account. These were considered high importance because these features directly defined what StudyTerminal should do to help future users achieve their desired goal.

Middle importance listed session details title change, current session user, change of main icon depending on session status and notification pop-up. We decided to change title of session details box to indicate if user is editing the details of an existing session or creating a new one. For current session user conflict we decided to display picture/name of the current user on the home page to identify who us currently using StudyTerminal. For notification pop-up we decided to have a notification text box pop-up for 3 seconds and then change the color of the notification button to alert the user.

Low importance listed map refresh button, clear direction for leave/end session, join new session pop-up, shortcuts for favorite/saved session and novice user wording. As we were discussing we realized that some features were unnecessary hence decided to think more about implementing them to our design in the future and not just yet. We had to make decisions on whether we wanted to follow our design style or to take in every feedback and heuristic evaluations to farther develop StudyTerminal. It took us awhile to go through every detail of heuristics and user feedback but realized how important and necessary it was to make our design better.

Design changes and revised prototype

by Erik Brown

Design changes

Thanks to thorough feedback, we had a list of problems with our prototype and most of the problems had general solutions mapped out. Now we had to make the changes on our prototype to meet our plans. We held a meeting to make our major design decisions and split up the development of our Balsamiq prototype.

Major design choices:

  • How would we handle login? While originally we were aiming to use Facebook for our logins, we now had feedback that this wasn’t enough. We instead will be implementing our own login system that utilizes Facebook accounts as supplementary. Users will be required to provide a UCSD email to register.
  • How would we handle interactions between users? We decided to add a ‘friends list’ that users can use to invite each other and to be used for managing individual privacy. While chat is a stretch goal, it isn’t core to our functionality so we are putting it on the side for now.
  • What information is needed for a session? Originally, we were planning on having mandatory fields such as course and location, but we revamped this system to give the user more flexibility. We now have a tag system, so the creator of a session can add only what they feel is necessary.
  • Should we be able to see public sessions or only those of friends? We decided that having an option to join groups that you aren’t already friends with is a critical function that we were missing. This broadens our target audience, and makes the site substantially more useful. By limiting accounts to UCSD logins and giving users the ability to control group privacy, we were able to alleviate many of our original security concerns. Making a login system also made the public session option feasibly.

Minor features that helped to meet major user needs, such as:

  • Confirmation button: Several dialogues now have a confirmation alert (leave session, end session), and similarly a pop up box to indicate that something occurred successfully (signup, settings changes, friend added).
  • Visibility shortcut: We added a shortcut from the homepage that toggles between visible/invisible status.
  • Provide a way out: Since many pages did not have a clear way to exit, we added a small ‘x’ to the corner of most pop ups.
  • Icon choice: Many of our app features are indicated by icons, but these icons were not always clear. We revamped our choices in icons and added text to explain many of our options.

For Balsamiq, we started by building a home page that we could work off of and then establish what other pages we needed, and split these up by group member. We chose not to focus on aesthetics, but made sure that our prototype expressed all necessary functionality of our site. Our group was then able to build off of the links we had on this page and our login page.

Home Page
List of Pages and Login Page

We received more feedback on this prototype and established two things to focus on during our transition to high fidelity. The first is the use of our check mark. Originally, we wanted this to be a focal point of our app and to be the thing the user was drawn to and would click on. However, our users didn’t seem to know what it did. Instead we are using an alternate image and will be adding a button that allows the user to create a session. Our other main issue is that we are not optimizing our use of space, which we will solve by modifying the layout and reducing the size of our logo. Going forward our primary goal is to keep our site simple for the novice user and optimized for the advanced user, and to prevent reintroducing any heuristic violations.

Check mark and revised icon for session creation

Hi-Fidelity Prototype

Updated by Johnny Chau, John Shin

As you can see, we used balsamiq to create our low-fidelity prototype. We arrived at the final iteration of our low fidelity prototype after taking into account the suggestions from user testing. The previous iteration mostly consisted of changes to the functionality of our application, and not the design. In this final hi-fidelity prototype, we’ll be considering different designs to make our application aesthetically pleasing and intuitive to users.

More User Testing

Before making our hi-fidelity prototype, we decided to get users to test our low-fidelity prototype and we asked them for feedback on the overall design. We approached two different groups of users and both groups pointed out that our layout is plain and suggest we implement a color scheme that is visually impactful. They liked the new Create button, but did not find our logo visually appealing because of the white background.

Bringing it All Together

Once we consolidated the feedback, we got to work and started to brainstorm on how to add some spice to the layout. As almost none of us had an eye for design, we stumbled on finding a color palette that would be visually appealing to our user. We started out testing with some colors that ranged from deep light blue all the way to bright green. As we worked our way through palette after palette, we arrived at a type of gray. We still didn’t like it. So, we reframed our approach. Instead of selecting a color palette, we’re going with a background image we feel represents the core of our application. A picture of the mothership, Geisel — our school library.

Our Lightbulb moment

After being completely lost on finding a suitable color palette, the picture of Geisel allowed us to find colors that complement the background of our application. We opted for lighter shades of gray and orange along with a deep light blue. With the help of Axure, we created our final prototype which you can see below.

Takeaways from the design process

Working on Study Terminal for the past month has been an eye opening experience for us. Before coming together to design the website, none of us could have foreseen just how long and arduous the design process could be. We learned some important lessons in time management and delegating work among members efficiently. We had some trouble in that aspect and were often working against the clock to meet the deadline. It’s important to recognize each group members’ strengths and weaknesses and assign duties accordingly. As such, we found that it was also helpful to have members come from different educational backgrounds.

One of the most important lessons we learned was the need to be flexible with design decisions. We learned through user testing that what we think looks visually appealing and is highly functional might not be so pretty or functional. It’s important to keep and open mind and try to take yourself, as the creator, out of the picture and instead think about what the user wants.

We also learned just how difficult small, seemingly inconsequential design decisions could be to make. Color schemes were a huge pain for us as we hadn’t given it much thought until very late in the design process. The inconsistency between the pages were an eyesore and it took several iterations of the design to get it right.

Our Final Product

We went through many iterations to streamline our website. In the end this is the description for our final version of the site:

Study Terminal is a simple to use website that allows users to organize study sessions with fellow students. It offers all the tools you need to find friends to study with — without all the hassle of sorting through unnecessary information as you would if you were using Facebook.

Presenting our Design

After testing our final prototype to make sure that everything was in working order, we organized our work so that we could present our idea. We compressed all of our design ideas into a fifteen minute presentation. The presentation consisted of four main parts.

The first part introduced each member and led into our pitch. The second part focused on the problems that we face and how Study Terminal would help remedy that problem. We shared some of our design challenges and ideas. The third part of the presentation was a series of short demos showing users how to create and manage sessions, how to change view modes and show notifications, and how to toggle the help feature. The final part of the presentation dealt with the future of Study Terminal and how we plan to grow our website.

Our intro slide

You can view our presentation slides here. Overall, the presentation went well. We got our message across in a succinct manner. There were some suggestions made during the Q&A section of our presentation that were interesting and worth considering.

A group picture after the presentation

Thank you for following and reading our posts.

--

--