Terms

Acceptance Testing

A phase in which the product is tested in the real world by the intended audience.

User Testing

Technique used in user-centered interaction design to evaluate a product by testing it on users.

Skeuomorphic

A design concept of making items represented resemble their real-world counterparts.

Native App

A native app, written for a specific hardware platform, will always run faster than a Web app, because there is no translation processing taking place.

Web App

A web application or web app is any program that runs in a web browser. It is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the application.

Scrum

A Scrum Team is a collection of individuals working together to deliver the requested and committed product increments.

Sprint

A sprint is a process for answering critical business questions through design, prototyping, and testing ideas with customers.

Agile/lean

Agile is a group of software development methods supported iterative and progressive development, wherever needs and solutions evolve through collaboration between self-organizing, cross-functional groups. It promotes adaptive designing, evolutionary development and delivery, a time-boxed iterative approach, and encourages speedy and flexible response to alter. it's a conceptual framework that promotes foretold tight interactions throughout the development cycle.

The Art of Guerrilla Usability Testing

Guerrilla testing in a way, is a fantastic method to quickly test something and get result right away without going through the hassle of a traditional controlled testing environment. The result you're getting from Guerrilla testing could be completely arbitrary because you won't know what kind of stranger you're approaching. The participant could also be shy away from giving their honest opinion due to the presence of the designer.

Personally, I can see the appealing aspect of guerrilla testing, but ideally its something that I rather not do. Approaching random strangers and subjecting them to test your product is a real turn off for me. I rather prefer voluntary tester.

Survey Money Question

1. Have you ever used a mobile application that let you pay your parking meter through your phone?

2. Would you install and use a mobile application that let you pay your parking meter through mobile payment?

3. Have you ever used your phone to pay for any products or services, if so then when or what is it?

4. Would paying a parking meter through a single tap on your phone(after initial setup) be more convenient to you?

5. If there is an phone application that let you pay your parking meters using mobile payment, how would you think it would be like?

6. Do you drive a vehicle as a your main form of transportation? If so, would a mobile application that let you located nearby available parking spot be of any use to you?

7. Do you agree that finding a parking spot should be made easier?

8. Have you ever lost the location of where you parked your car? If so, would a mobile application that let you save the location of your parked car be of any use to you?

9. Do you currently have any parking application installed on your smartphone? If yes, what is it and how do you feel about it?

10. Are you willing to pay a subscription fee to make your parking your car less of a annoying process?

Painless Parking FlowChart

UX v UI Laymans Guide

I think it a pretty good article. "Design and Code in Parallel" is a awesome idea. I think as soon as the designer completed a rough sketch or layout of sort, the developer should go right ahead and begin coding that layout. While coding the layout, the developer might detect a issue that could be of a great help to the designer in reducing future error. I think the whole project would work best if designer and developer work side by side rather than working separately and point fingers at each other later during the testing phase when a problem appear.

"Don't over-formalize the process" is another great key point to take with you. Before, I always thought that formality and professionalism is the way to go, and it would present yourself as someone who knows what they are doing and are highly skilled, but in a way I guess it can cause stress and tension within a team. Too much formality can push away the sense of open invitation of communication within a team which is never a good thing for promoting teamwork.

Unituitive Lesson on being a Designer

I feel like most of the stuff the article cover here, has been beaten into our head by the professor here over and over, which is no doubt the best method of teaching a important value. One of the key idea that stood out to me was #5 "If you don’t want design to be treated as a service, you need to have an opinion about what problems are worth solving and why." It's nice to have people come to you with a problem and asking you to solve said problem, but it more appealing to discover a problem you're passionate about and solved said problem. In other words, its better to take charge and lead rather than take orders from others.

"At the end of the day, the people whom we are designing for don’t have any of that context, history, or understanding of the constraints we face. And yet, they will still pass judgement."

Some how I can relate to that message above. Your design is the result of a process you went through and people who didn't go through that process is criticizing your work. In a way, you're automatically think their judgement have no value. But if you open up, and accept those judgement, and build upon it, it will definitely make you a better, not just designer, but also a better person.