<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Komentarze do: Zakupy w jednym kroku</title>
	<atom:link href="http://www.webusability.pl/2010/01/20/zakupy-w-jednym-kroku/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.webusability.pl/2010/01/20/zakupy-w-jednym-kroku/</link>
	<description>Web usability, użyteczność i dostępność.</description>
	<lastBuildDate>Wed, 07 Dec 2011 22:37:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
	<item>
		<title>Autor: Tomasz Tybon</title>
		<link>http://www.webusability.pl/2010/01/20/zakupy-w-jednym-kroku/comment-page-1/#comment-14243</link>
		<dc:creator>Tomasz Tybon</dc:creator>
		<pubDate>Mon, 15 Feb 2010 22:03:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.webusability.pl/?p=317#comment-14243</guid>
		<description>Nie zapominajmy o tym, że użytkownik przychodzi na stronę w określonym celu. Jeśli mówimy o &quot;stałym&quot; użytkowniku (czyli takim, który już ma konto w sklepie/serwisie) &quot;mentalnie&quot; może on szukać obszaru logowania, a biorąc pod uwagę, że ten obszar jest zlokalizowany w górnej (wcześniej widocznej części strony) dostrzeże go zanim przejdzie do wypełniania danych adresowych. W źródłowym poście jest mowa o przeładowywaniu strony np. po wpisaniu kodu promocyjnego. Wprawdzie nie mamy podanego ekranu dla usera posiadającego konto w sklepie, ale śmiem zakładać, że po zalogowaniu może mieć wybór adresu dostawy lub wpisania nowego, a z pewnością pola uzupełniają się stosownymi danymi z konta (przynajmniej jak znam styl Lindy Bustos i pozostałych osób z Elastic Path).</description>
		<content:encoded><![CDATA[<p>Nie zapominajmy o tym, że użytkownik przychodzi na stronę w określonym celu. Jeśli mówimy o &#8222;stałym&#8221; użytkowniku (czyli takim, który już ma konto w sklepie/serwisie) &#8222;mentalnie&#8221; może on szukać obszaru logowania, a biorąc pod uwagę, że ten obszar jest zlokalizowany w górnej (wcześniej widocznej części strony) dostrzeże go zanim przejdzie do wypełniania danych adresowych. W źródłowym poście jest mowa o przeładowywaniu strony np. po wpisaniu kodu promocyjnego. Wprawdzie nie mamy podanego ekranu dla usera posiadającego konto w sklepie, ale śmiem zakładać, że po zalogowaniu może mieć wybór adresu dostawy lub wpisania nowego, a z pewnością pola uzupełniają się stosownymi danymi z konta (przynajmniej jak znam styl Lindy Bustos i pozostałych osób z Elastic Path).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: Krzysztof Spilka</title>
		<link>http://www.webusability.pl/2010/01/20/zakupy-w-jednym-kroku/comment-page-1/#comment-13884</link>
		<dc:creator>Krzysztof Spilka</dc:creator>
		<pubDate>Sat, 30 Jan 2010 09:49:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.webusability.pl/?p=317#comment-13884</guid>
		<description>$300 Million Button;) a tak poważnie, to testy A/B są naprawdę świetnym narzędziem - jak widać na powyższym obrazku. Próba 606 nie jest duża, a wyniki więcej niż zachęcające.</description>
		<content:encoded><![CDATA[<p>$300 Million Button;) a tak poważnie, to testy A/B są naprawdę świetnym narzędziem &#8211; jak widać na powyższym obrazku. Próba 606 nie jest duża, a wyniki więcej niż zachęcające.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: Marek Kasperski</title>
		<link>http://www.webusability.pl/2010/01/20/zakupy-w-jednym-kroku/comment-page-1/#comment-13689</link>
		<dc:creator>Marek Kasperski</dc:creator>
		<pubDate>Fri, 22 Jan 2010 10:47:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.webusability.pl/?p=317#comment-13689</guid>
		<description>Case jest interesujący, to prawda, nie jestem jednak przekonany do kroku 1. Jest dla mnie jasne, że taki układ strony dużo lepiej obsługuje klientów okazjonalnych. Natomiast jest problematyczne w jaki sposób obsługuje klientów z założonym już kontem?

Problem polega na psychologicznym akcentowaniu jednego rozwiązania (wypełnienie formularza adresowego) i przytłoczeniu drugiego (logowanie). Obawiam się, że w rezultacie może to prowadzić do tego, że użytkownicy nawet mający już założone konto w sklepie i pamiętający hasło, w ramach procesu zakupowego, gdy zobaczą stronę z tak wybijającym się na pierwszy plan formularzem adresowym, będą go wypełniać zamiast się logować.

Ktoś by mógł powiedzieć - no i co z tego, skoro sprzedaż jest lepsza? No tak, ale zawiązanie jednorazowej transakcji nie dla całego e-commerce jest priorytetem.</description>
		<content:encoded><![CDATA[<p>Case jest interesujący, to prawda, nie jestem jednak przekonany do kroku 1. Jest dla mnie jasne, że taki układ strony dużo lepiej obsługuje klientów okazjonalnych. Natomiast jest problematyczne w jaki sposób obsługuje klientów z założonym już kontem?</p>
<p>Problem polega na psychologicznym akcentowaniu jednego rozwiązania (wypełnienie formularza adresowego) i przytłoczeniu drugiego (logowanie). Obawiam się, że w rezultacie może to prowadzić do tego, że użytkownicy nawet mający już założone konto w sklepie i pamiętający hasło, w ramach procesu zakupowego, gdy zobaczą stronę z tak wybijającym się na pierwszy plan formularzem adresowym, będą go wypełniać zamiast się logować.</p>
<p>Ktoś by mógł powiedzieć &#8211; no i co z tego, skoro sprzedaż jest lepsza? No tak, ale zawiązanie jednorazowej transakcji nie dla całego e-commerce jest priorytetem.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

