Team Betamax Needs Analysis

Problem Statement

Olin College is a small school with a diverse, creative group of faculty and students. Since the faculty and students come from so many different backgrounds, it is no surprise that there are many different avenues for information dissemination within Olin's community, both academic as well as extracurricular. Olin's IT department has provided BlackBoard, which is supposed to fulfill the role of a web portal for classes and some students groups. A majority of Olin's students and professors feel that BlackBoard is either poorly designed and executed, insufficient, or both. As a result, a myriad of non-BlackBoard course websites have sprung up, either hosted on faculty operated servers or on faculty web space provided by Olin. Each professor has a different policy, and sometimes professors make use of both a course website as well as a BlackBoard site. Student group and project pages are even more numerous and tend to be hosted on just about any available server, from personal desktop computers being run out of dorm rooms, lab computers, IT servers, and faculty run servers. As the student body grows and changes at Olin, the problem is only getting worse.

The IT department at Olin has rolled out a web portal, with the caveat that the portal is not intended for students. The portal software they are using is a Jenzebar product which is intended to replace the archaic telnet interface that the financial services department had been using. Even though the portal isn't designed for students, it still has access to a number of student-specific data sets, such as grades, course enrollment, GPA projection, degree audit, and financial information. Most of this information is available on the Student Information Services (SIS) page, and is, quite frankly, formatted and presented in a much better format there. The portal has frequent double links for the same page, and often requires the user click multiple times to advance themselves down the navigation tree. Ordinarily, this is not particularly unusual, but in this case, there is only one relevant option for the user to click on each step of the way. The most glaring flaw is the fact that the passwords apparently are stored in plaintext in the database, which, while not a interface design issue, is an uncomfortable security risk. The Jenzebar portal does have some potentially useful features, such as a bulletin board messaging system, but because of its other, detrimental, features, it has never been used other than as a novelty item, if at all.

Of course, there are a number of fairly well designed portals that already exist on the web, such as Google personalized home pages, Yahoo! personalized home pages, and various ISP-specific start pages like myEarthLink. The problem with these pages, of course, is that none of them can access internal Olin resources. Additionally, none of these existing systems are suited for Olin specifically, because they don't have the capability to interface with Olin's email and calendar systems, nor can they access student data regarding grades and billing. In the scope of this class, we hope to design and implement a web portal for Olin students that ties together their academics, extracurriculars, email, calendars, and any external to Olin information they desire--weather, Red Sox scores, etc in a simple and easy to modify package.

Back to Top

Information Gathering

Our information gathering process consisted entirely of interviews with our users. Our group had two rounds of interviews. The first set of interviews was with our original set of questions. We interviewed in two groups, Doug and Joe, and Jon and JJ. Following this round of interviews, we met as a team to discuss our findings as well as refine our set of questions. Doug and Joe did a second round of interviews with the refined set of questions. During both sets of interviews we also asked our users to perform a few tasks, which are detailed below.

We had also intended to get some users to write down all the websites they looked at in a given day of normal activity, or send us their browser history. As a first pass, we did this to ourselves (since we, as Olin students, are technically in the user group), and have not further pursued this line of inquiry.

First Set of Questions
  • How do you figure out what you're going to do today?
  • What do you use the 'net for?
    • How much time do you spend on the 'net?
  • Do you use social networking sites such as Facebook?
  • What information do you regularly look up?
    • Sports scores?
    • Stock quotes?
    • Weather?
  • Does the term RSS mean anything to you?
    • How do you get your news?
  • What is your current homepage?
    • How much time to you spend on it?
  • What's your browser of choice?
  • Where do you store your contact information?
  • Where do you do your calendaring/scheduling stuff?
  • Do you use the ACL's NNTP services?
First Set of Interview Activities:
  • Portal Interactions
    • Google IG
    • Yahoo!
    • BlackBoard
    • Olin Portal
  • SIS
  • Try to find course/faculty webpage (preferably one you haven't been to yet).
  • Watch them websurf
Second Set of Questions
  • Do you use anything besides Outlook for scheduling?
  • Do you use Outlook for anything else besides email/calendar.
  • Do you use portals now?
    • What do you think?
  • What information do you regularly look up?
    • Sports scores?
    • Stock quotes?
    • Weather?
  • Does the term RSS mean anything to you?
    • How do you get your news?
  • What is your current homepage?
    • How much time to you spend on it?
  • What's your browser of choice?
  • Do you use the ACL's NNTP services?
  • Do you keep ToDo lists?
    • Online or on paper?
Second Set of Interview Activities:
  • Portal Interactions
    • Google IG
    • Yahoo!
    • BlackBoard
  • SIS
  • Try to find course/faculty webpage (preferably one you hav en't been to yet).
  • Find someone's phone number: "Make my phone ring"
  • Write down all the websites you visit for a day or so

Back to Top

What We Found

From our interviews we were able to come up with three personas, a user lexicon, and some goals and values for our personas.


Since personas are so important, we gave them each their own page.

  • homepage
  • link
  • organization
  • customization
  • [access to] information
  • conglomeration
  • to-do
  • task list
  • schedule
  • email
  • Outlook
  • meeting request
  • iCal
  • news
  • weather
  • course websites
  • blackboard
  • SiS
  • homework assignments
  • personal
  • surf
  • 'Net
  • "Google Knows"
  • Facebook
  • mailing list
  • randomness
  • carpe diem
  • helpme
  • log in
  • log out
  • password

Back to Top

Translation Into Interaction Needs: Task Matrix

Task Matrix
Check Homework
Daily, Important Task
Daily, Important Task
Daily, Important Task
Check E-mail
Never, Uses Gmail
Never, Uses Outlook
Never, Uses Outlook
Check Schedule
Never, Google Calendar
Never, Uses Outlook
Never, Uses Outlook
Check Tasks
Does not use Tasks
Does not use Tasks
Never, Uses Outlook
Portal Web Search
Several Times a Day
Several Times a Week
Once or Twice a Day
Find Contact Info
Twice a Month
Twice a Week
Once a Week
Manually, mornings and after class
Stored in browser, logged in automatically Stored in browser, logged in automatically
Change Password
Every 3 months
When she has to
Forgot Password
Every 6 months
Not memorized, pass stored in browser
Not memorized, pass stored in browser
Customize Portal
Initially, and again every one or two weeks
Initially, and maybe once or twice thereafter
Initially, seldom afterwards

Back to Top

Explanation of Process

We conglomerated the results of our user interviews into a collection of activities and goals and used this information to develop representative personas characterizing our 3 primary user "types". We then assigned a frequency to our users tasks based on the percieved importance to, and individual characteristics of, each persona. Our lexicon represents commonly encountered vocabulary when conversing with users or designing interaction narratives for our personas.

Back to Top

Comparative Analysis

There are several currently released products that act as web-portals. Two of these, PhoenixNet and (SIS) are internal to the Olin Community. Additionally, blackboard (BB) is a product used within the Olin Community, but available to all higher education facilities. Also compared are the Babson Portal (accessible using a Babson student account) and (Google IG), a customizable home-page/portal developed by Google designed for the general public.

Phoenix Net

Phoenix Net (also called is a portal customized for the Olin Community by Jenzebar, Inc. One problem that immediately arises is that it must be viewed over a secure channel (https), and no redirect is provided from Users log in using their Milkway (Windows) credientials. Without first logging in, users can see a list of "handouts", and "Resources", the first being explanatory PDFs for enabling e-mail access and the later being links to frequently accessed Olin sites. After logging in, the page changes subtly to include new tabs for "Campus Life" and "Students". Throughout the various pages, bookmarks are classifed as "ungrouped" and "student-submitted", and clicking on titles can bring up an editing interface that can only be described as "clunky". Clicking on a subheading on one page brings up a menu to change the name, on another page, performing the same action has no effect. All in all, the interface is an improvement over previous versions, but is still too confusing or useless for most users (as evidenced by the fact that no one has posted any messages for general consumption.)


Student Information Services ( or SIS) is appropriately named and available to the Olin Community by Jenzebar, Inc. Like Phoenix Net, SIS's replacement service, it must be viewed over a secure channel, but unlike PhoenixNet, SIS provides a redirect service from Previously, a seperate system was required for logging into SIS (known colloquially as SIS username and SIS password, the username was a student's ID number and the password was generally the same.) Now, SIS requires students to log in using their domain name (e.g. astudent) and old SIS password. SIS provides straightforward links to content for grades, financial info, registration (by far the most common use of SIS) and academic record. SIS is not designed as being a "portal" like Phoenix Net, but is generally the best place to find academic related information at Olin.


Much can be said of BlackBoard (, also BB), an academic portal provided by BlackBoard, Inc., and at Olin, most of what's said isn't appropriate for a professional document. Students log in using their Milkyway network credentials, and are greeted with information about the few courses in the system. It should be noted that you can't leave these courses unless the professor removes you, so for example, one student is in a course on BB he took over a year ago. The content for the frontpage is semi-customizable in that users can add some content, but some content can't be removed. A poorly-kept secret within the Olin Community is that BB is used by Financial Services and other departments more than it's used by students and faculty.

Babson Portal

The Babson Portal ( is a site available to all babson community members. Users log on with a Babson username and password. The site automatically takes information from Babson's BlackBoard and also many external feeds (, weather). Calendar Sharing and E-mail options are also available. One negative is that the default set-up floods the page with information, and customization is possible, but difficult to navigate.

Google Portal

Customization is key on the Google portal ( A google username and password is required for logging in. Users can add content by searching for what they want (weather, sports, etc.) and small boxes appear on the main screen. Google IG is integrated with GMail and Google Calendar, but no integration is currently possible with Outlook or BlackBoard, so it's unsuited to student's needs. While great for beginning and intermediate users, the extra load time is cumbersome for advanced users, who probably get identical information elsewhere (firefox extensions, keywords, bookmarks).

Back to Top

Initial suggested design, with justification.

The first step is to sever the link between the academic aspects of the college and the administrative aspects. This portal will not be designed for inter-department communication at Olin.

As of this moment, our design would start with a minimum collection of features, namely: an RSS reader for course and student group sites with RSS feeds, static links to pages without RSS feeds, and a clean, easy to navigate organization. The incorporation of newsgroups may also go into the basic model. This design appeals to us for its simple approach and clean, efficient, user-content centered portal. A more ambitious version of this project may include Outlook-like features such as e-mail, a calendar, contacts and tasks, as well as SIS functionality. Additionally, students will be able to add some external RSS feeds from enjoyed websites (e.g., CNN, ESPN, Gmail) and other quick-glance information (Weather, Stocks, etc.) to the portal.

The reason why we are planning to build the portal in phases as described is because this is not the first time this project has been discussed at Olin. During the 2005-2006 academic year, the OlinWorks co-curricular did sporadic work on the portal project. While the project never got off the ground, some initial design decisions had been discussed, and it had been decided that the most important features were the ability to aggregate news feeds from both on an off campus and have static links to course websites that didn't provide news feeds. A majority of Olin students live in the Windows environment, so for their purposes, Microsoft Outlook serves as a perfectly good email client and scheduling program. As a result, less emphasis was placed on these two components. To further exacerbate the problem, the IT department is reluctant about allowing access to the Exchange server and SIS server (with good reason), making those aspects of the project harder.

For the purposes of the project, we will ignore the potential backend issues, but will still try to follow the phases. Of course, we don't know if the sentiment from the rest of the student body will support our choice of phases, but we will have to wait for the interviews before that can be determined.

Back to Top

Teamwork Breakdown

TaskTask WeightAdamDougJJJon


Interview Planning1%25%25%25%25%




Users' Goals5%0%0%50%50%

Task Matrix5%0%0%75%25%


Process Description1%0%0%100%0%

Comparative Analysis5%100%0%0%0%


Initial Design Ideas3%0%0%0%100%


Back to Top