Boonjour NM4210!

Heeding advice from lecture notes and hints from Mr. Reddy that he would prefer something more surprising and unique, we decided to go ahead with our ‘risk’, attempting to create a unique UX that’s true to our theme rather than following classics/popular styles that’s routine everywhere. We particularly took inspiration from the lecture notes that mentioned that LOOKS is vital in UX.

All these piles up and we decided to go for our flash prototype, which would ultimately resolve most of these intricacies. But it was a risk, it was something we ideally envisaged, but was slightly less confident that it would be acceptable to the peers. We would also have to revamp and tweak our initial idea a wee bit so as to encompass more of the peers’ feedbacks, plus energizing our final prototype with sound lively background sound loop. It all went so smoothly. Thankfully, we persevered and persisted with it, and our eventual presentation was an incredible bang (we really did not expected it)! It yielded astonishing responses from the crowd… even receiving loud applauses and a real standing ovation! That’s really something we appreciate a great deal as designers, and that probably in a way, sums up our UX Evaluation.

USABILITY TEST

In carrying out our usability evaluation, we employed the popular Think-Aloud protocol, in which testers are supposed to voice out while they are interacting with the product. We would also slightly observe their reactions when interacting, as non-verbal cues do tell something. We have gathered 6 evaluators, mainly Targeted personas (3 advanced, 3 novice) to perform one of the 3 assigned tasks that we have conceived, so that users would not be in a frantic on what to do, but pre-occupied and focused on fulfilling a task. I was given the task of a facilitator, briefing them on the overview, the objective of the test and a brief demo as well as prompting them to ‘think aloud’.

* From Top to Bottom (L-R): Splash, News, Carparks, Booking, Help, Express Booking, Register.

Assigned Tasks

The 3 tasks as mentioned earlier on, are as follows (Booking – Task 1 & 2, Information enquiry – Task 3):

TASK 1: Booking a lot at Plaza Singapura the night before a movie.
Pre-requisites: Movie Tickets already bought, and car-park lots are readily available at Plaza Singapura.

TASK 2: Booking a lot at Plaza Singapura, 2 hours before movie.
Pre-requisites: Movie Tickets already bought, and car-park at Plaza Singapura is fully booked (need for alternative car-parks)

TASK 3: To locate car-park status of a mall at lunchtime.
Pre-requisites: Information seeking, car-parks have ample lots, seeking for alternatives as well.

Results
Generally, all evaluators managed to complete the assignment tasks successfully.
There were essentially no major predicaments, but the process of completion was slightly slower due to interacting with the system for the very first time. As for information enquiry, the process was very smooth, evaluators appreciated the efficiency and were pleasantly surprised that alternatives car-parks were presented to them, even though they have initial anxiety in using the feature.

One of the observations I personally took noticed was that, at first sight of the website, they were already impressed, but were skeptical towards the functionality of the website, whether is it smooth-going (they felt good looks = less behavioural benefits). But with increasing familiarity they begin to appreciate and even begin to like the website and its feature even more. This is essentially Berlyne’s model of aesthetics: Eventually with even greater familiarity we like them less, and look to other designs.

UX EVALUATION
After reviewing all the possible ways to measure UX, we decided to go for a two-pronged approach, of measuring two attributes which we felt was essential:

• Emotions, and
• Pleasures

EMOTIONS

In measuring emotions, we deployed the use of James Russell’s affective model: Circumplex of Emotions, that was mentioned in the lecture notes. We wanted to know how exactly our product have affected or aroused the user. Using a list of 6 expressive positive and negative terms, users were asked how they were affected by the outlook of our product.

Positive Terms

2. Inspiration
3. Desire
4. Pleasant surprise
5. Fascination
6. Amusement
7. Satisfaction

Negative Terms

2. Disgust
3. Unpleasant surprise
4. Disappointment
5. Contempt
6. Dis-satifisaction
7. Boredom

The responses for emotional evaluations are tabulated in raw average scores as well as modeling after James Russell’s Circumplex of emotions, and are clearly shown above, with relatively high inclination towards the positive appraisals, which was really flattering.

PLEASURES
As for pleasures, we really want to know how our product can make the users content is which aspects. Hence, we deployed a 5 point likert scale questionnaires based on 4 pleasures framework, where users are to evaluate on a list of questions ranging from physio, psycho, socio and ideo pleasures.

Generally, users appreciate the novelty and details put on the website. Experience ranks high among others (navigation and buttons play a rather important part), and they were generally excited about the product, which we are really pleased with. I guess aesthetic really plays an important part in UX. It simply catches attention, may it be positive/negative (positive in our case). It embeds no clear definition, but you feel it defined almost instantaneously when users are delighted by your product.

PEER FEEDBACKS
Besides the standing ovation that really surprised us, peers remarked that our inclusion of tiny features such as auto-complete of user inputs in textfields and auto-cursor locality, did help to elevate the UX. The testers also commented that the audio (which was not presented) was suitable to the theme.

Not to foget, peers also remarked on the effective usage of flash in our prototype. As they were having a debate in the earlier presentations over some of the peer’s technical implementation of their idea using flash, not being appropriate, they felt our Flash implementation suited the carpark theme ideally. One of the followups was that had our idea been implemented in static HTML, it might have lost its magic. Wonderful, they felt.

I felt that one of the factors that led to our successful UX delivery is all about, perception management: Looks, function and feel. We tried to really handle and take care of most touch points relevant till this phase (possible entry points): Product, packaging, brand, distribution, support, media. Also, sensorial design playing an effective role: it gave a prelude and sort of first impression. Last but not least, users’ power! Users feedback really gave us room to further enhance our product. Without user’s opinions, we would have been stuck at some point, not moving up to the next possible level. As such, UX experience is really, user-oriented and user-centric. Kudos to the users and evaluators, who have contributed to our project in one way or another. Deeply appreciates!

We were really excited at this phase because finally, we can realize the style that we want to implement in our website. As mentioned previously, we wanted to adopt a style that’s really true to our theme. Moreover, booking websites sometimes seems solemn and mundane; we’re trying to break this norm, to further enhance booking experience, just like what Donald Norman reflected in his blog ‘improve the experience of completing a task that everyone has to do, but that very few of us enjoy’. As such, we attempt to adopt sensorial design into the booking and registration procedures, believing that attractiveness would make booking work out better. We did some preliminary analysis into which elements we could possibly use to bring in the car-park feel to the cyberspace, eventually deciding for the combination of cars, car-park and gantry, signboards, LED screens, and car-park kerbs, plus web2.0 style buttons and feel and finally some real affordance in buttons’ textures and clicks. It is, really, about bringing conventional physical car-parks into the cyber world, something that we have yet to observe in the web as yet. And that is somewhat akin to the Von Restorff effect, of increasing likelihood of remembering unique or distinctive events.

Design Initiatives
We have actually designed some worksheets to specify design guidelines, such as interactivity level, elements which we can utilized, as well as developed some colour palettes (color themes) to guide us through the entire prototyping phase.

We have actually prepared (doing too much work? ) two prototype styles, one that is visually pleasing with cool car graphics but meant for a static webpage that’s quite commonplace, and another one that (we really wanted to try it out) is dynamic, graphical, interactive and unique, that has room for the X-factor. In both cases, we try to plug in what we had learnt from the lecture, LOOKS. We were rather inspired as we thoroughly believed that good looks form an un-explainable X-factor that would give u the extra push, and for our case, it’s the entire packaging of the website. However, as both versions have their merits, we were really undecided which one to go for: the former being more safe, the latter being more unique. Furthermore, as first impressions always count – make or break, do or die, we really want to capture user with a pleasant surprise.

Nevertheless, we opted for to present the former for our first presentation, for a first try. The static version was sort of acknowledged by the peers, but they seem to be rather unsurprised. I guess our first impression didn’t make it well enough.

Furthermore, peers commented that were that the prototype looked somewhat cluttered and Mr. Reddy pointed out that there was some inconsistency due to the fact that there were too many versions of different cars in each scenes. Hence, there was a need for more coherence and immaculation (cleaning up so as not to be so cluttered). Below are the extracts from our heuristic findings.

Jakob Nielsen’s Ten Heuristics Feedback (Key pointers of 6 evaluators):

Visibility of System Status
The prototype received good reviews at this section. There were good comments that praised the LED screen at the center of the curvy navigation bar that indicated where the user is navigating at, exactly and obviously. Also, they commented that the system showed effectively the steps and which steps they are now, for both booking and registration procedures.

Match Between System & Real World
There were generally good comments at this segment too. Comments were kind as they were satisfied and understood the headings, which was relevant to car-park terms – ‘NEWS’, ‘CARKPARKS’, ‘BOOK-A-LOT’ and ‘HELP were pretty instinctive. Moreover, they felt that the car park theme was really ‘in attendance’ in the website (even the navigation bar has some stripes that sort of reminisce the car-park kerbs).

User Control & Freedom
There were some complaints here. Generally most people were lost in booking and registration because they have no way to get back to the previous page (especially the data entry form page). Well, we have to admit, we were too intrigued in getting the whole prototype that we forgot to include some ‘back’ or ‘edit’ buttons. Sorry! We’ll resolve this!

Consistency & Standards
The more critical ones is the confusion between “News” and “Information” links of the navigation bar. They sound too similar, and yes we will be changing ‘Information’ to a more suitable header name. Some do not understood ‘BOOK-A’LOT’ but it was mostly due to the fact that they were probably too excited by the prototype that they forgot the fact that it’s a car-park portal, hence the ‘BOOK’ metaphor din really catch up that quickly into their recognition.

Flexibility & Efficiency of Use
They were impressed with the express booking feature, that being more familiar users, they can opt to go for express booking which was much more simpler, and as the system would retained their information (IU, name, mobile number, etc), its makes it all more convenient and it helps to speeds up the whole process a lot more.

Aesthetic & Minimalist Design
The color themes that we had applied (corporate colours as derived from above), were clearly noticed and distinguished. The website in white, grey and red – were consistent colors throughout the entire website, now that’s safe. Furthermore they were impressed with the outlook of the website, that looks really hip, new-generation and attractive, they find it ideal to the theme of carpark. This is essential the Aesthetic-usability effect – phenomenon where people perceive more-aesthetic designs as easier to use than less-aesthetic designs – whether they are or not. However, the use of so many different cars in various screens making it quite distracting and inconsistent.

Help & Documentation
Good feedbacks on this area too. The assistance links such as help and contact us were visible throughout the website, regardless of where the user is at. They felt this was commendable.

Error prevention + Diagnosing & Recovering from Errors
The prototype did suffer at this stage, as being a prototype, the system wasn’t connected to backend database, hence it is not workable as yet. Hence, error messages as well as validations were not as complete either. Hence, there was some limitations in this respect.

Heuristic Evaluation:
Generally, we did fare well in some areas, notably Visibility, Flexibility, Aesthetics, Help sections. However, as the prototype is not entirely a complete workable system (that’s not connected with a database), so sections such as the error preventions and helping users diagnose and recover from errors, are not that complete yet. While we are concerned, it is not entirely worrying because what we’re supposed to deliver at the end is a high-fi prototype that deals mainly with interactive design rather than system validations. Moreover, error preventions and validation is something that would be instinctively resolved should the real implementation be carried out. Hence, no frets! On the whole, we still have plenty to do for the prototype, following the heuristic feedbacks, both design wise and functionalities wise. Hence, we will be revamping, moving from this static version to our exciting flash and more coherent implementation next week.

First Feedback
The first user feedback that we received for the prototyping phase, prior to the low-fidelity prototype, is that there wouldn’t be a need for an ‘explicit’ search function. The background for this is analogous to that of Golden Village’s website, whose non-existence of a search engine did not seem to impair its daily operation. As such, users’ main search will be on car-parks, which is already available in our ‘View Info’ section. Hence, taking inspiration from this, we voided the idea of the search function in our website, which would not be in consideration for the low-fidelity prototype.

Design Overview
Our design theme was to bring the car-park feel to the cyberspace, which we realized through our research for similar sites on the web, is really non-existent. As such, we are really on the verge of creating a novelty UX experience. The theme of our design would include porting over the car-park elements as visuals in the website, such as the cars, car-park kerbs and lot markers, car-park gantry, etc to be interconnected with our Park-A-Lot (PAL) synergy. We have the idea of a unique UX experience on the back of our minds, only waiting to be hauled out in the prototyping (low and high fidelity) phase.

Prototyping Exercise
Moving on to the low-fidelity prototype, we followed pretty closely to the storyboard of information workflow that we have drafted our in the previous entry, and create a paper prototype of 12 screens, for users to trial and reflect on. We chose paper prototyping for its speed, as it is an incredibly fast way to mock up an interface for no coding is required. Another value-added point of paper prototyping is particularly relevant to our cause, to find a rather wide range of problems in our interface, including many which might be serious ones. As this is a really novel system, whose navigation and workflow could not readily be researched on the web, we have to really rely on users to provide us what how they would navigate. As such, we intend for the prototype to help in establishing the navigation and layout uncertainties.

Prototype Samples

Prototyping Feedbacks
We adopted a persona-targeted approach in gathering the users for our low-fi prototypes. On overview, the feedbacks did surprise us. Though we’re not expecting our prototype to be great with no flaws, but we did not expect to so many feedbacks! However, we felt it was great, as problems can be alleviated early in this design phase. Users did provide us with some really good feedback that we’ve overlooked. Great insights into how users would navigate and their different needs.

Due to the nature of paper prototyping, we were unable to acquire anything on the technical aspect of the systems, particularly the actual flow of the system (the correctness of info conveyed across), but we received clear, useful suggestions on enhancing our low-fidelity for the better. As there were really too many feedbacks to screen through, we will just exhibit the ones that we felt was critical and which we will really consider for the next prototype.

They commented that the layout of the site was somewhat peculiar. They questioned the need for so much space occupied by the navigation bar, as it looked too chunky/blocky. However, it was due to the fact that we are intending to create a more unique style of navigation, which requires more space and more graphics then the common practices of websites. It was really hard to pin it down on paper, so we just use blocky squares to represent them. Some also remarked on the visibility of ‘Back’ buttons for bookings. A good point taken, as we did overlook this aspect. Some do not understand the meaning of ‘Book-A-Lot’, however we felt, it was intuitive enough. Lastly, they were not impressed with the prototype’s feel. They preferred clean, neat and uncluttered layouts, while our seemed to be too cluttered, heavy and ‘abnormal’. The reason for a more unique layout was that we felt that approaching the website with a normal presentation would not provide users a distinct “UX” that’s true to our theme. We decided to go an extra mile to create a new UX that truly relates and complements to our novelty idea of car-parking online (bring parking to cyber world).

We noticed one disturbing problem throughout the various prototyping sessions. Most users, as this stage, prefer to take the safer option: opting for the normal/routine/common ways that they would accept. On hindsight, we are seeking for a different unique feel, and they find it hard to accept, at least in this low-fi prototype. Hence, we have the unsettling dilemma of: whether we still go for the unique way? Or should we go for the safer but more boring way? However, the nature of low-fi prototype was rather inadequate for us to present the visual style we would like to exhibit to the user, hence, we can’t lay out our judgments on this as yet, because they have yet to get the feel what how we want to present the website hence there’s still a need to develop hi-fi to give user the feel of what we hoped for.

The consultation session with Mr. Reddy was as usual, intriguing and beneficial. We received really good input from our UX guru, Mr. Reddy. There were particularly 3 great main ones, which we would definitely take into consideration. Mr. Reddy voiced out that: For seeking car-park information, rather than comparing two user-selected car-parks, he would prefer to see nearby car-parks generated by the system, to be presented along with the car-park that he had selected. That way, if that car-park is unavailable/full, he would not have to decide which one to go for next, as the system had already presented him the nearby ones. That would definitely give a pleasant UX to the user. Also, Mr. Reddy finds our prototype pretty normal for now, but he understood that due to the nature of prototype being low-fi, the visibility of X-factors would have to wait till high-fi prototype to be unleashed. He did encourage us, to try out new things though. Another critical and great point is that Mr. Reddy advised us to use regional booking rather than specific lot, very true indeed, solved a few of our perturbing issues with booking a specific lot.

Reflections
Despite having substantial benefits of low-fi paper prototyping, we realized a particular impenetrability. While we were drafting out the paper prototypes, we deeply felt that in paper prototypes, its really not easy to bring out our intended UX experience to users, as yet. Many a times, we wanted to put in more details on our design concept (to port over car-park feel to cyber world), but find it hard due to paper form. But that led us into appreciating the significance of high-fidelity prototyping: as it really made us keen to reach the high-fi prototyping phase as soon as possible, for that’s when we can finally bring out the design to the users and see if our designs gives them a new experience.

We also realized that paper prototypes are really a part of our iterative design approach, where we constantly need to evaluate and refine designs with the results of testing at each cycle feeding into the design focus of the next cycle. And indeed, more iteration meant more enhancements which could lead to definitely a much more focused and user-centric design. It also encourages creativity from the product team and users alike in realizing a better system; otherwise the idea would come to a standstill, which might be be all-covering.

Also, from the prototype, we finally realized what the lecture was trying to tell us. The perception of a product is based on the individual values of the user and the context of use. Indeed, perception of user experience is highly subjective, we receive so many feedbacks due to each user having different point of views. We felt that all feedbacks have to be screened through and considered, but not necessary to be implemented. Careful analysis and evaluation have to be taken into consider. Also, the intended feel that we hope to present to the user is often perceived wrongly by them, that explains wrong we often have to reiterate the design theme that we are applying so as to make them understand what we’re doing. This clearly is what the lect is trying to tell us too, intended experience is not necessarily the perceived experience.

Lastly, as we were stuck in a dilemma on whether to follow the classic website’s way of presentation or to risk trying out a new style of our own. After reviewing the lecture notes, and heeding Mr. Reddy’s advice, we decided to risk it, try out the style we always wanted to experiment. It might just turn out well. Hence, reflections quote of the week (from lecture notes), that really made sense to me now:

We create our own experience; don’t stick to rules, open up more perspectives, only then can new experience be derived. (Dead poet society)

Setting Up The IA Framework
The emphasis for this week is on mounting the Information Architecture (IA) for the project. Heeding Mr.Reddy’s advice for an improvisation of various IA techniques to encompass an maximum coverage on user’s partiality, we decided to go for a hybrid of our own IA style: Improvising cardsorting + persona-focused, observation + common task analysis + storyboard. Why a person-focused cardsorting, you might have asked? Because our idea is a novelty, we really wanted it to zoom into our target users, hence person-focused cardsorting would make our IA more target-focused.

Our IA Approach

* Cardsorting
We did a preliminary analysis, brainstorming all possible attributes that could come out from our head, that would connect with our carparking theme, effectively coming up with a content inventory of approximately 40 odd items. We then filter the inventory list by striking off either duplicated or highly similar items. With that, the list was shortened further and eventually identified 30 main items for users to perform the cardsorting on.

Needless to say, cardsorting itself is a useful tool that is exceptional in identifying how users group data, as well as how they would make the data flow. As what was mentioned previously, we are going for an improvised approach in gather user groupings of data: Targeted persona card sorting. As such, we will be approaching users directed from our Advanced and Novice personas, but voiding Anti-Users since instinctively due to credibility issue; they wouldn’t be keen on our proposal anyway, hence their results might be highly biased and pre-disposed. With all the settings in placed, we arranged for 12 sessions of cardsorting, a mixture of online (generic, overview) and offline (targeted, focused) sessions.

For the offline (targeted) group of users, we have actually prepared the materials: physical sets of 30 cards and coloured stickers beforehand, for them to physically perform the cardsorting process. We begin the sessions by briefing them, highlighting our intentions of this test, introducing the tools (cards) and showing them a quick demo on how to do it: grouping by pasting colour tabs onto item cards. For this specific group, we also kept a close eye on their actions, observing their expressions and reactions when card sorting. We felt that it was necessary to study the context in which a task is being performed by observing and experiencing tasks as from that, we can identify which are the tasks that are really intuitive and which requires closer thoughts.

As we hope for more user feedbacks for identifying common groupings between user, we decided to branch out our IA to more people via the online group. We discovered a great tool, that’s free of charge, interactive and helpful in results consolidation into excel: the online cardsorting exercise via Optimalsort.com. We setup our cardsorting questionaire on OptimalSort.com, including some introduction and highlights that would guide them through on our exercise. They are then required to name classification categories, of how they would group the items by dragging and dropping into these categories. Through this online group, we would be hopeful of settling the disparities that could arise between diff point of views in classifying certain items, which would indirectly help in better establishing the majority’s common perspective.

* Common User Task Analysis
The online results were compiled similar to that of offline card sorting sessions. The OptimalSort results consolidation tool made life simpler for us, so what we eventually did was to use eye-ball analysis to identify common groupings between users. Out of which we discovered readily the following groupings:

a. Carpark Info
b. Booking Info
c. Member Details
d. Statistics
e. Viewing of live Info
f. Search
g. FAQ

With the above common groupings identified, it made life easier for us as we are able to analyze further and identify the common user tasks associated with them. Identifying common user tasks are essential because they would be what that what defines the system and associates the user with the system. As such, the 6 key user tasks, based on what we unearthed in the previous sections are:

1. Search
2. Log In/Out
3. Registration
4. View Info
5. Website Booking
6. SMS Booking

* Storyboarding
These 6 common user tasks would be pivotal in our next step: Storyboarding of information workflows. With common groupings and common user tasks in place, we analyzed all possible workflows, refined and derived a flow chart of information/procedural flow for each common user task. Each flow chart would be analogous to that of a procedural cycle. As such, we have to down key details such as process descriptors, user’s interaction, process input and output, so as to fully document the storyboard. The storyboards (an example shown below for booking) would be particularly vital in the next phase: prototyping, which we are really excited about.

Reflections
IA is probably one of the dullest phases that we had anticipated before its arrival. As mentioned in the previous post, being students in Computing, we rarely seek feedbacks from users, and it had somewhat affected us in our entrance into this IA phase. We (Alvin and I) often felt that IA is redundant, that we can also decide for the users, such as ‘Now these are the links, these are exactly what you have to do to reach this step’. We wanted to organize the content for the website or application directly, often having the urge to go straight into doing our way, but were often reminding ourselves to focus on users. Hence, we thought it would be a ‘formality’ procedure. But we were proven wrong. We were somewhat surprised by the outcomes of cardSorting. Some of the classifications are really what we never thought of, and it seems to be such a good remedy for a few of our dilemmas. What we would have done, is really different from what the users have provided us. It really brought us another perspective, which is really more ‘accurate’, since it would be really what the users one. This provides valuable input for understanding the natural categories people have for the content before we begin the design of the new structure.

One point that we constantly remind ourselves is to observe the users, and it’s a really useful technique for our cause. The notes that we took down while observing our offline users helped a great deal in our decisions for identify common user’s task. Furthermore, we realized, as programmers, sometimes our point of view is confusing for users. This is very true indeed, after observing and comparing how users group and how we will do it our way. We are also thankful that we sought the feedbacks from the online group of users, as it really aided us aplenty in concurring the disparities arising between the offline targeted users. We achieved greater insights into what the common groupings will be. However, we sincerely believe that for massive projects, we really need to conduct and consider the inputs from users (targeted):

Reflection quote of my own: Every users are unique; everyone have different ways of grouping, but most have something in common. Hence, even when it’s impossible to please all, we should at least try to please the common majority.

Laying The Groundworks
With the Needs Analysis last week seemingly won over the class of the car-parking idea’s potential, we progressed to the next phase of the project: drafting out the requirement specifications for the product. To assist us in gathering forthright insights into user’s need and expectations of our impending solution, we gathered users (mainly drivers) for a focus group to get their open feedback and initial reactions as well as hear them discuss their preferences for our solution.

The focus group yielded a fruitful session, where we can evidently notice significant needs in the final product. The more noteworthy ones that are more central to the product UX are as follows:

• Timeliness: car-park information should be realtime and up-to-date (status, availability).
• Directions: booking procedures should be clear & succinct.
• Credibility: for booking, user must be notified and assured of the lot acquired
• Navigation: ease of browsing (organized and intuitive).
• Accessibility: alternatives way to access information (Internet & SMS).
• Speed: service should have minimal latency.
• Affordability: service should be free or of minimal cost.

Having laid the groundwork for user’s expectation in the impending solution, we then have to formalize our target users, ascertaining them as drivers who visit frequently during the packed out hours the car-parks that will be implemented in our service. Within them, we categorized two significant groups of potential users: namely the convenience seekers and price conscious, whose characteristics are pretty implicit.

Specifying The Requirements
Now we’re right on track for the serious business! Adopting a user-centric design approach in drafting the functional requirements , we track back and refer to an important document that we had done up previously, the informal list of user’s needs. From them, we formulate 3 main genres of requirements that would be definitive for our eventual product: the aesthetics, workflow and interactivity.

To be concise, aesthetically, users are hoping for a clean and visually pleasing website that has a balance of visuals and animations, yet bearing the element of simplicity. Information should also be organized and should be too cluttered up. Workflow wise, users seems to be justifiably frustrated with having to navigate deep into websites to acquire the things they want in their previous experiences. Hence, they do not hope to see this problem happen in our implementation. Clearly, they are seeking for minimal navigation effort (minimal clicks to intended service or option: we’re hoping for less than 3 levels of navigation). As a plus point, they would also hope to have different alternative modes of accessing the system. In terms of interactivity, users emphasize on design concepts of affordance and mapping. They hope to manipulate the website in a fashion that us familiar to them. They hope to receive prompt feedbacks through friendly sound and animations rather than typical error message, as well as the ability to interactively manipulate statistical information when comparing carparks. As such, we have to utilize appropriate animation & user interaction to enhance user experience.

Keeping these 3 categories in mind, they will vital in guiding us in keeping to the right track in the later stages, notably design and prototyping phases to deliver the user experience that we hope to bring out.

Emergence of Solution
One more step ahead! We’re finally ready to define our impending solution.
We hope to deliver an informational and booking system that will integrate car-park information across the various car park venues & operators. Target venues would be car-parks that are already digitally installed, such as town and CBD areas (and in future, we could expand to neighbourhood areas like AMKHub, Tampines which are digitally installed).

The product should empower drivers to plan ahead without having to be physically present in the car-park vicinity to check the status. It should also allow users place bookings effortless which, in a way, grants assurance of being able to acquire a lot, that would negates the sense of uncertainty that they previously encountered. The product would also present various alternative modes of operation – Internet & SMS so that information can be readily accessible anywhere, anytime. More importantly, the product itself should provide a definitive car park-ing experience by overturning present negative car-parking attitudes into a pleasurable and positive car-parking experience.

Staging Experience Strategies
Now, we’re lacking a very important fraction of our product specifications. What good is a UX product if it does not encompass good experience strategies? No worries, We had it all covered. Inspired by Apple, we felt it was necessary to establish dynamics that ensure the product achieves the feel that we hope the user to uniquely experience with our product. To be short and snappy, these are the more vital ones that is pivotal to our experience strategies.

• Key Differentiator
  - Users’ pleasurable experience of acquiring car park lots
  o without being physically present and laboriously sourcing for one
• Sensorial Aspect
  - An experiential approach of satisfaction
  o Sense of achievement, comfort and relief
  o Saving time and physical effort
• Symbolic Aspect
  - Novelty to date
  - Combining physical car park with technology
  - New experience of car-parking
• Meaningful/Practicality Aspect
  - Convenient and efficient one-stop driver guide and tool
  - Provide timely and prompt information
  - “You’ve got it” sentiment

To conclude the product specifications: ultimately, we hope to present a solution that would transform car-parking experience into a pleasurable and assuring experience.

Peer Feedbacks
As we did not bring in GPS into our presentation, questions were raised on the exclusion of GPS in our solution. We actually included GPS in our implementation, but besides the lack of time in implementing it for this module, the adoption rate of GPS also isn’t that widespread in Singapore as yet. That is why we are shelving it GPS implementation off for now, deciding to focus on the 2 channels that are already common utilized in SG (SMS & Internet). Nevertheless, it was a good point raised by as we too, foresee that GPS in Singapore will be commonplace in years to come, and an imminent GPS implementation of our system would definitely enhance the user experience of car-parking to a higher level.
(For more insights on the increase in adaptation of GPS, please refer to the article quoted in my teammate (Alvin)’s UX blog)

Reflections
Honestly speaking, I’d learnt a great deal in the preparation for the deliverables for this phase. User-centered approaches are indeed advantageous, although I felt it was rather tedious and time-consuming, as it is indeed a laborious iterative process: every week we have to get back to the users, and then analyze and evaluation findings.

As part of computing students and programmers, very often we do not seek user’s opinions in our projects. We do not understand or even bother how the things we develop will affect the users. Hence, many times in this project, I often have the tendency to sway away from seeking user opinions, thereby needing the extra effort to keep reminding myself to keep probing users. It was only till the interactions with the users, that changed my standpoints entirely. I felt that delving deep into user’s needs and requirements did gave us surprisingly new and different insights to explore, sometimes they are really useful suggestions and even perspectives that I had never and perhaps could never envision before. However, as we’re still dealing with a very small sample size of users, there might be a need for more users to participate to get a more balanced evaluation. That aside, I would really think that it is through these users, who could be turn out to be our eventual end-users, that we can develop a product whos functional specifications is exactly something that is really close to their heart. And perhaps, that’s what defines a fine User Experience.

After all the turmoil last week, we finally hit the road and got off to developing a more comprehensive Needs Analysis for a ‘mock’ pitching proposal and pitching presentation to the class as users. This is a vital phase as it’s supposedly a make-or-break instance: we have to justify the need and convince the class that this is indeed a need to unravel, before we can ultimately advance and develop the product.

The Preparation
My team went into another enduring session of brainstorming early in the week to get ready the contents for the proposal and presentation. We took a systematic approach, researching into present car-parking experience: identifying target users, a preliminary investigation into the problems of present car-parking experience, possible modes of delivering, and the potential benefits of solution. With that, we laid the foundation of a mini literature review as well as the overview concept of what we hope to materialize.

We decided to probe further for our needs analysis, questioning more drivers this time round, and more probing into the problems they face with present car-parking experience: whether car-parking appeals to them as a positive or negative experience, what they would hope to be done to resolve this, and which are the things they will be looking towards for in the impending solution. From there, we move on to the collating the data of the user’s need surveys from all team members, analysis and evaluating them to produce a concise Needs Assessment.
A general synopsis of what we had analyzed from the Needs Assessment is the majority of drivers in Singapore actually have a negative perception towards car-parking in Singapore, particularly the town and crowded CBD areas. They felt that car-park lots are scarce and expensive, and the queue before entering the car-parks is particularly maddening. Very often the queue is often so long at peak hours and weekends, often causing traffic congestion as they stretch from the main road right to the entrance of the car-park, leaving them at a standstill, practically motionless and helpless. Worse still, they felt a sense of uncertainty and clueless about the then car-park status, and were at a complete loss at how long they have to wait to secure admission into the car-park, not to mention on finding the rare available lots within the car-park. As such, the mental states of these drivers generally perturbed, highly impatient and extremely exasperated, but they had no choice but to endure as this is generally the way of life for driving in Singapore, they felt. This is a very typical Singaporean issue indeed, and we are pretty positive that these user’s sentiments would be substantial in convincing the users that we will be encountering in the presentation.

The Day Has Come
Yes, the anxious day has arrived. Following the lecture, Mr. Reddy commenced the mock presentation. One by one, the groups pitched their projects in the hope of convincing the class of their ideas. To be honest, I was pretty shocked at the way the session had progressed, especially for the first few presentations (the ‘improved’ IVLE and Food ones in particular); the class was pretty heated u and hostile! To be exact, many groups were devastated when their presentations hit rock-bottom, hurled with never-ending ‘missiles’. Some audience apparently do not see eye-to-eye with the ideas, more often the part in concurring whether the idea was genuinely a need. Even though the group justified their stands, some audience persistently and critically questioned that most of their needs are not exactly needs, but more of ’self-wants’ and ‘improvements to existing implementations’, which are the needs for only small fraction of the community. For some, the benefits (product) of their needs seem to be of little significance to the community, which left the audience quizzical about the feasibility of team’s possible solution to the need. However, I felt this is way too premature to pronounce.

Crunch Time
Very soon, it was our time to present. With all the tension heated up, we were really uneasy, but were prepared and cautious. Thankfully, for our presentation, it was a breeze as most of the class got the gist of our needs analysis and were generally receptive towards it as a need. Although many of them aren’t drivers, they understand and were aware of the frustrations that their family encountered when trying to park in crowded places. Of course, there were some doubts on inherent physical infrastructure as well as the uncertainties surrounding the novel approach in making car-park ‘bookable’ online. For these queries, we had foreseen them coming and hence we were rather smooth at tackling them. With regards to the novel approach in making bookings online for car-park lots, its common that people will be skeptical but its still to early to tell, but we’re pretty convinced that it will work out. As for the physical infrastructure, it’s trickier. As we’re developing an interactive product to transform the car-parking experience, the physical infrastructure is something that we cannot possible lay our hands on, unless we’re really implementing it with the real official authorities that allows us to do so. But yes, although we can’t liaise with the authorities, we still did our homework in coming out with the various possible solutions and alternatives in modifying the physical infrastructure (subtle modifications so as not to affect too much on existing infrastructures).

But the most comforting moment has got to be instance after our presentation, our closer friends turned to us and commented “hey, great idea, one of the best in class!”, remarking that it’s indeed is a good need (and a real massive need that a solution to it would definitely entice the entire population). Ultimately, while there are a few reservations surround the implementation, the class generally felt that this might be the solution that would revolutionize car-parking experience for the better, which was good, exactly what we hoped to achieve!

REFLECTIONS
I strongly feel that there are plenty of UX issues out there that remained unsolved. However, we often fail to notice/ think of them, and more often, we complicate things by thinking that the UX remedies would be complex and knotty, but we did not realize how simple the need can be resolved. For our case, negative car parking experience is a prevalent issue, everybody knows that but seemingly everyone thinks that it would take a hero to resolve this tricky ‘experience’ issue. But the fact is that a more pleasurable user experience can perhaps be achieved, simply by providing accessible information for people to plan ahead. Though simple, it brings out a totally different (hopefully positive) user experience.

Also, with regards to all the presentations in general, it seems apparent that user experience and needs does varies from people to people. While some finds certain issues a need, some don’t, due to different inborn settings, upbringing, perspectives and experiences.

Ultimately, I felt that life experience and exposure is a factor in UX receptivity: to justify users of their needs, as well as for the user to understand and be convinced.

The Early Blow
My team and I began brainstorming on ideas way ahead before the official commencement of the project. Inspired by the physical product that Mr. Reddy mentioned: the Kneon beer bottle, (as we thought that creating a physical product would be more interesting than creating interactive web content), we went towards that direction of creating physical products, coming out with a lengthy shortlist of ideas comprising of: a multi-functional female urinal (of various designs), 5-way highlighter that is slim and handy, shirt hanger that digitally adapts to fit the varying sizes of shirt, and even rebranding of Thinkpad laptop through LED screens on the laptop cover to change perception of Thinkpad as a hideous and unexciting laptop.

We were really keen on presenting these ideas on that preliminary proposal session with Mr. Reddy, but was devastated (really shattered) when these initial ideas were utterly slammed and rejected. An entire month of effort was practically wasted! Mr. Reddy did not agree with our multi-function female urinal as he felt this product already existed and adding functions to it will not be appealing, and he went strongly against the idea of rebranding Thinkpad, as he felt rebranding isn’t the focus of ‘needs’, particularly this module isn’t about branding.

The Wise Man Speaks
Mr. Reddy raised up an important pointer that entirely changed our perspective of the final project (for the better). Instead of going in the direction of creating the new products first, then addressing the need, the focus should start with identify user’s needs; REAL needs that existed, and then focus on solving them through the product. It only made sense, and woke us up entirely as we were blindly heading in the wrong direction! It was very true as we had the dilemma of having a new product that we tried to forcefully add interactivity to it and then tried to convince ourselves it was a need.

It shouldn’t be that way.

Nature Took Its Course
That really woke us up and gave us a correct direction to head to. Now comes the big brainstorm: identifying user needs in present setting. I was pretty frustrated initially as I realized all possible needs that I can think of seems to be already solved, and sometimes they are solved so simply. Yet, I firmly believe there must be a need somewhere, which we never realized. Deciding to reflect on common needs relevant to my social circle (as commoners in the population), I realized a rather significant need that’s commonplace which I’d overlooked: the need to transform car-parking negative experience. There are plenty of antagonists in Singapore who are really frustrated with parking in town (some do not even want to drive but take public transport to town areas), and the uncertainty when queuing only makes driving n parking unpleasant and annoying. This struck my mind and gave me a surge of motivation: Why hasn’t someone tried to resolve this problem? Maybe I’m the first? Went on to research online on such systems, no results! Not in Singapore, not even in other countries, I guess I’m creating a novelty, something that I’d never thought of, but this might be it!

Conveyed the idea across to the group and they seem rather excited by this need. To double-confirm, we followed up with some quick dialogue with our family and friends, whom we asked just one simple question: is car-parking during weekends frustrating to you? A unanimous ‘YES’, certifies that it indeed is a need. Furthermore, when they knew that we’re developed a product to alleviate this issue, their face lit up surprisingly but pleasantly, seemingly glad with the idea. It really is intuitive; focus on real user’s need, product would naturally prove useful.

At the same time, Alvin came up with the iCalorie suggestion, which was also an ideal need, due to health concerns reported in both TV News and Newspaper that Singaporeans aren’t health conscious in the food they are taking in. Stuck between the 2 ideas and undecided, we arranged a crunch-time consultation with Mr. Reddy to seek his opinion on the feasibility of these 2 ideas. He seems fine with both ideas as they both seems promising, but he has a preference for car-parking as he felt more strongly that the car-parking need would prove rather fruitful. He was supportive and interested towards it, furthermore it was something that was unique and different from the previous batches. Thus, that marked our start (finally, after so many ‘bumps’ and ’swells’ mentally), and our progress for this novelty got underway. We are excited!

A good lesson learned indeed: Mr. Reddy’s wise reminder of the approach of examining needs ahead of products, eventually made the process all so natural and convincingly for the eventual product, that naturally requires interactivity.