tu e il progetto

it/tu_e_il_progetto/00_Tu.md

@@ -0,0 +1,9 @@
+#2. The project & you
+
+To work on the usability of a project you don’t need specific usability expertise – just the passion to learn and apply it. This is well described in the UX Advocate program started by David Siegel of Canonical and promoted by Allan Day of GNOME. Although it unfortunately didn’t gain enough traction, the motivations behind it are very true: 
+To be a UX Advocate, you don’t need to be able to create pixel-perfect mockups in Inkscape or have an HCI degree. All you need is love – you have to love an open source project and the people who use it, and you need to be patient, persistent, and persuasive. Of course, if you have some background in user experience, that would be tremendously helpful, but it’s unnecessary; it’s far better for an open source project to have a novice UX Advocate than none at all. 
+Siegel (2010)
+A UX Advocate doesn’t need to be a developer. They don’t even need to be a usability expert (though they can be on their way to becoming one). What they do need is the time, energy, and inclination to champion user experience. A UX Advocate can triage and prioritize UX bugs, and they can research design problems. They can even do user testing. 
+Day (2010)
+This document is exactly for making that as easy as possible. 
+

it/tu_e_il_progetto/01_Usability.md

@@ -0,0 +1,7 @@
+#2.1 You are a usability person
+
+If you’re a usability person looking for a project to improve, don’t pick any project but one useful to you. Independent free & open source software is about scratching one’s own itch (Raymond, 1997) so you should do it in a similar fashion as a user representative (Nichols & Twidale, 2003). You should be committed to the project and know it inside out. 
+The other developers are volunteers as much as you. Just jump in and do your best, your work will be appreciated. In contrast and as an advantage to paid usability work there is no constraint set by clients as to how the test should go. You can freely assess which methods you use and how many (or rather few) participants you interview. 
+Many free software developers already know about usability and the importance of it but don’t know how to improve it. A big issue in working with them is a lack of trust (Andreasen et al., 2006, p. 309). That is why you have to openly communicate your findings and methods. Ideally educate the developers about testing methods and common usability problems so they are enthusiastic about it themselves. 
+The earlier you do testing, the better. No developer likes throwing away lots of his code, especially those working in their free time. And this shouldn’t be the issue holding the software back from being more usable. Communicate your findings early and often (Reitmayr, Balazs & Mühlig, 2006). 
+

it/tu_e_il_progetto/02_Developer.md

@@ -0,0 +1,10 @@
+#2.2 You are a developer
+
+Awesome that you read this! This document should give you ideas and provide you with methods on how to improve the usability of your software. Even if there is no designer on your project, you can use many of the research methods yourself. 
+One of the most important things in usability is that […] the product should target people whom [you] consider to be clueless newbies (Trudelle, 2002). Everything should be as clear and self-evident as possible (Krug, 2008). You already know the interface inside out and probably even designed it. Hence you tend to either overlook or simply not notice issues (Johansson, 2005). 
+To learn more about general usability and develop an eye for issues, these blogs should go in your feed reader: 
+Jakob Nielsen’s Alertbox: The guru of web usability, usability testing and low-cost usability methods. 
+Little Big Details: The small interface details which are rarely noticed but help so much. 
+UX Myths: The most common user experience misconceptions and why they are myths. 
+Lukas Mathis’ ignore the code: He writes at the intersection of software engineering and user interface design. 
+