PROJECT SCENARIOS, COMPETITIVE ANALYSIS,
AND PRELIMINARY DESIGN ......1 | 2 | 3

Preliminary Design

Initial Design Process
1. Registration Process [SFnight Prototype Evaluation | Initial Design ]
2. Planning an Event with Friends for Tonight [Initial Design]

..........................................................................................................................

Initial Design Process

The group members worked independently and brought some initial drafts to a meeting. We decided to use just paper-based sketches to facilitate the creation process at any time, any place. The idea of using DENIM would be good if we had more time explore the tool.

1. Registration Process. Wwe started by reviewing the registration process, which is represented by the Chris scenario. We first had an overview of SFnight Final Project [SFnight FP] issues regarding registration and then defined some important elements that should drive the design decisions. We felt the need to restart the design from the beginning and some of us went back to the computer to check other sites practices besides the ones we had researched.

Important Elements in Our Design Decision:

• Preserve anonymity: Besides SFnight FP has defend the idea of preserving anonymity, two of our personas have concerns about privacy issues. We would not require address, real name, but e-mail was necessary to give the Rick or Stefan a unique identity, while being easy to remember. Also e-mail would be a way to provide the user his password in case in forget it. Chris is not so aware of those issues, but started to discuss this issue with other classmates.
• Password: We tried not to use this word, since people like Chris would be confused with their private e-mail password. A way to solve this was to say something like "Create mySFnight password" or "Create mySFnight code"
• Newsletter: It became an option, instead of mandatory thing. Stefan don't want to receive. He prefers to check the site, or receive by mobile. We also identify the need to provide registration from any page. To solve this, we suggested to include in the left navigation bar a short cut to sign up SFnight newsletter. We created an easy way to register for newsletter, for those users who does not want any personalization at all. We discussed a lot how this could be simple, and what kind of feedback it would be need, besides the next steps if users change their minds. Specially the feedback pos-signup, and the e-mail confirmation.
• Register No! Hong brought his experiences about this word, that does not sound so friendly. We decided not use it, and we are preferring the word "Sign up" or "Create". And also this remind us that Stefan hate this word. He feels like been in a cashier, and he wants to have entertainment when he comes to SFnight!
• Optional versus Mandatory. Things that were Optional should be more explicit to Chris, and in special for Stefan and Rick that does not like to give much information. Our personas might feel more comfortable in filling the form that they have freedom to choose which information they will include.
• Personal information: For business strategy and for better understand user needs, SFnight needs to know "gender, age". But those are optional. If, per example, SFnight is focused in people of 27-35 years old, and its users are more likely 18-23, the SFnight strategy might be change to achieve its goals, or be redesigned to better meet its current users. How to understand if they are more like Chris or Stefan?
• For Tickets/Promotions, a complementary form on-demand. We also decided that if some one would buy a ticket, would have a complementary form for the user first buy/or promotion. But these information would not be part of registration process. Stefan and Rich would not sign up if have to ask personal information. Chris for been inexperience would easily put her info, but we would like to protect our users, and provide them anonymity.
• Backend Issues. We discussed issues related with ways of recognizing the user, how the backend would treat this: if Chris has to sign up in two computers (from home and at the cafe she work for), if the computer does not allow her to create a cookie. We decided to follow the standard practices. For Leonardo this would not be a problem since he carries his laptop everywhere, but for the Stefan and Rick having to sign up every time would be a pain.

Registration Process Initial Design

After those concerns, we concluded that the Registration Process is not a simple design: there is business, privacy, technology issues that should be taken into account.

Sketches of the SFnight Prototype Evaluation focusing in our personas and our Initial Design is presented.

2. Planning an Event and After Event

Important Elements in Our Design Decision

• SFnight Personal areas are: (a) "MySFnight at a Glance", a quick view from Sfnight homepage, focused on top events for tonight or following days, in case there are no options available; and "MySFnight", a personal homepage customized by two processes:
  
  1. During the registration process, the user selects his favorite events type.

2. When browsing an event/or venue profile, the user can pick them to add to his favorite ones at MySFnight.

• MySFnight at a Glance, or whatever will be called, already exist at the current prototype, and was based at the Amazon model. The idea is to present a quick view, if the user just want to quickly glance the SFnight home page. We will analyze at the design stage if small thumbnails will appear too much at this area. Also the personas would need to have a quick access to update preferences, and to remove it. We would need to make more clear the difference between MySFnight at a Glance and the real one.
• MySFnight, has to be appealing enough to make our personas interested in making this an active page. For users, like

Stefan, having the events organized by week days would be better. But it should not appear as another calendar. He will not have time to edit. Also have a quick access to his favorite venues, would make his nightlife more easy.

Rich, probably will make a collection of venues he would like to try, and since he likes to write some reviews, have a quick access to them.

Leonardo and Chris, probably will pick some DJ music to have some entertainment, and also use the Venue listing to see what explore next. They are more interested on events of their taste.

• The differentiation between MySFnight for consumers and Network for players should be clear. Although the final project people should check how they could provide MySFnight to players at the same time of Network [for example, bar owners might want to have a quick view of their main competitors at their Favorites]. But also solve a problem if the consumer, once registered, later become a player [a promoter, for example]?
• www.mysfnight.com For business reasons, and also analysis of the different goals to be achieved by MySFnight, we decided not to have a www.mysfnight.com page, which would allow users by pass the homepage. Our design follow the News/Amazon approach, and not the Yahoo model. There are relevant search functions at the main page that we would not like to repeat in the mySFnight page. Different from a portal, SFnight would like to provide also the cultural sense of San Francisco, and not isolate the user. New kind of music might become fashion, or user might want to try a different event by listen a music sample that is not at his/her favorites.
• Terminology. We would need to do a better study and come up with new terms, that does not have a clear function to users: (a) "Favorite Venue", might be used in different ways (for picking my favorites or for creating a list to Visit Next); in this case we decided not to create a new feature, but to see if we can find a better name that could incorporate those two different ways of using. h. At the main mySFnight, we would have the other features (My review list, Favorite DJ (but would not be part of our project) .
• Some other features we evaluated:
  Avoid list: Rich initially though to have a Avoid list of his bars. But Rick never wrote one line at this agenda. But at the other hand, he likes to express to his friends when he likes or not a venue. So this avoid list probably would be used once, and forgotten very quickly.
  Visit Next: This was absorbed by the Favorite venue. Too many listing for users.
  Calendar: We also evolved to a simple calendar: we mixed the Favorite Events type with a way of presenting in a week layout. This would be great for the users if implemented, and would solve the need of calendar feature, since some people might have different calendars and do not use other ones. It would be more one thing the persona start with and then give up soon. At this new formulation of "Favorite Events", Rick, Stefan and Leonardo, as well as Chris, would need to be able to pick some of them and send to friends what ever.
• Review: According to Rich scenarios, we would need to develop the rating process to include some categories at the Review-Rating form that would help consumers classify their evaluation, besides the comments.

Registration Process Initial Design

Sketches of our Initial Design for planning an event and after event is presented. Specially focused at MySFnight home page and then Review.

---

1 | 2