<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://palikowski.net"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>krzysztof palikowski - użyteczność</title>
 <link>http://palikowski.net/taxonomy/term/316/0</link>
 <description></description>
 <language>pl</language>
<item>
 <title>User eXperience w aplikacjach korporacyjnych</title>
 <link>http://palikowski.net/node/1397</link>
 <description>&lt;p&gt;Ostatnio w mojej praktyce zawodowej widzę, że coraz większą wagę przykłada się do użyteczności aplikacji. Wiele lat były one wytwarzane bez zwracania uwagi na ten element. Teraz firmy starają się jakoś wygrzebać z bezliku różnorodnych interfejsów, formatek, typów pól i sposobów na osiągnięcie tego samego. &lt;/p&gt;
&lt;p&gt;Dlaczego do tego doszło? &lt;/p&gt;
&lt;p&gt;Problem z często beznadziejną użytecznością oraz brakiem spójności w interfejsach aplikacji pisanych na zamówienie przez duże firmy dla dużych firm jest między innymi taki, że budżet konsumowany jest często jeszcze przed dotarciem do testów użyteczności. &lt;/p&gt;
&lt;p&gt;[drobna złośliwość]&lt;br /&gt;
W tym miejscu powinien wyskoczyć skrzacik albo diabełek i zapytać Cię, drogi czytelniku, &quot;W projektach korporacyjnych zawsze planujecie testy użyteczności na wczesnym etapie, prawda?&quot;.&lt;br /&gt;
[/drobna złośliwość] &lt;/p&gt;
&lt;p&gt;Wykonawcy aplikacji &quot;na zamówienie&quot; muszą spełnić wiele kosztownych wymagań  - integracja z wieloma systemami, szkolenia, testy akceptacyjne, poprawki z gatunku &quot;bo nam się przypomniało że...&quot;, dokumentacja analityczna, projektowa i techniczna (wiele razy przepisywana), dedykowane instrukcje stanowiskowe i tak dalej. To wszystko kosztuje.&lt;/p&gt;
&lt;p&gt;Co innego aplikacje pudełkowe, dla masowego odbiorcy. Tam raz zaprojektowana i napisana aplikacja sprzedaje się głównie dzięki temu, że jest funkcjonalna, użyteczna, estetyczna i przyjazna. Interfejs użytkownika (często sprawdzany przed kupnem za pomocą wersji trial) jest niemal krytyczną kwestią. Aplikacja musi nie tylko działać ale wyglądać i wyróżniać się na plus w gronie konkurencji. &lt;/p&gt;
&lt;p&gt;Wracając do aplikacji &quot;korporacyjnych&quot;. Przy pewnym poziomie frustracji związanym z przekroczeniem budżetu, terminów i granic zdrowego rozsądku jeśli chodzi o moment i zakres zgłaszanych poprawek i zmian, sporo projektów jest odbierana i wrzucana na produkcję na zasadzie &quot;skończmy to wreszcie a poprawiać będziemy na podstawie feedbacku użytkowników i po godzinach w ramach osobnego projektu&quot;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://palikowski.net/node/1397&quot; target=&quot;_blank&quot;&gt;czytaj dalej&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://palikowski.net/node/1397#comments</comments>
 <category domain="http://palikowski.net/taxonomy/term/315">ux</category>
 <category domain="http://palikowski.net/taxonomy/term/316">użyteczność</category>
 <pubDate>Mon, 24 Jun 2013 17:33:14 +0000</pubDate>
 <dc:creator>palikowski</dc:creator>
 <guid isPermaLink="false">1397 at http://palikowski.net</guid>
</item>
</channel>
</rss>
