<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Guillaume Paumier&#039;s weblog &#187; Wikimedia Foundation</title>
	<atom:link href="http://www.gpaumier.org/blog/tag/wikimedia-foundation/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gpaumier.org/blog</link>
	<description>open knowledge, design &#38; technology</description>
	<lastBuildDate>Thu, 26 Jan 2012 15:14:52 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>Wikimedia User experience programs: a systematic approach</title>
		<link>http://www.gpaumier.org/blog/503_wikimedia-user-experience-programs/</link>
		<comments>http://www.gpaumier.org/blog/503_wikimedia-user-experience-programs/#comments</comments>
		<pubDate>Thu, 04 Mar 2010 15:06:55 +0000</pubDate>
		<dc:creator>Guillaume Paumier</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Featured]]></category>
		<category><![CDATA[Wikimedia Technology]]></category>
		<category><![CDATA[Operations]]></category>
		<category><![CDATA[Software development]]></category>
		<category><![CDATA[Technology]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[UX]]></category>
		<category><![CDATA[Wikimedia Foundation]]></category>

		<guid isPermaLink="false">http://www.gpaumier.org/blog/?p=503</guid>
		<description><![CDATA[Where I discuss the benefits of a systematic UX approach, rather than having a separate UX entity. <a href="http://www.gpaumier.org/blog/503_wikimedia-user-experience-programs/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><em>During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the second of a series dedicated to this topic.</em></p>
<p><em><strong>Disclaimer:</strong> The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.</em></p>
<p><em> </em></p>
<div id="attachment_817" class="wp-caption aligncenter" style="width: 600px"><em><em><a href="http://www.gpaumier.org/blog/wp-content/uploads/2010/03/Japanese_Tea_pot_by_Denis_Savard640.jpg"><img class="size-medium wp-image-817" title="Japanese_Tea_pot_by_Denis_Savard640" src="http://www.gpaumier.org/blog/wp-content/uploads/2010/03/Japanese_Tea_pot_by_Denis_Savard640-590x393.jpg" alt="Japanese Tea pot by Denis Savard640 590x393 Wikimedia User experience programs: a systematic approach" width="590" height="393" /></a></em></em><p class="wp-caption-text">A Japanese teapot. Friends of Donald Norman will understand. CC-by by Denis Savard</p></div>
<p><em> </em></p>
<p><em> </em></p>
<p><em> </em></p>
<h3>Investing in <acronym title="User experience">UX</acronym> is a Good Idea<strong>™</strong></h3>
<p>Over the years, the design of MediaWiki has been solely driven by software developers. This has caused an unfortunate technology-based approach of the front-end and the features (implemented or missing), relying mostly on the implementation model. The consequence is that <strong>the interface &amp; features are too far from the users&#8217; mental model</strong>. The <a title="About the Wikipedia Usability Initiative" href="http://usability.wikimedia.org/wiki/Wikipedia_Usability_Initiative">Wikipedia</a> and <a title="About the Multimedia usability project" href="http://usability.wikimedia.org/wiki/Multimedia:About">Multimedia</a> Usability projects have tried to address the most pressing concerns resulting from this hiatus between the software and the users&#8217; expectations.</p>
<p>For all these reasons, I am really happy to see <a title="[Foundation-l] [Announcement] Extension of user experience work" href="http://lists.wikimedia.org/pipermail/foundation-l/2010-March/057017.html">the Wikimedia Foundation investing further in User Experience</a> (<acronym title="User experience">UX</acronym>). However, I see little added value in having an <acronym title="User experience">UX</acronym> department separate from the main development cycle. There are at least two reasons to keep them as one.</p>
<h3><acronym title="User experience">UX</acronym> should be a systematic approach</h3>
<p>A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; <strong>good, usable design needs to happen <em>before</em> the actual implementation of any feature</strong>, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it. A separate entity made sense when these <acronym title="User experience">UX</acronym> programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate <acronym title="User experience">UX</acronym> programs from the &#8220;regular&#8221; development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.</p>
<h3>Everything is <acronym title="User experience">UX</acronym></h3>
<p>More generally, <strong>all the activities of our Technology department are about User experience</strong>; everything we do is <acronym title="User experience">UX</acronym>. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users&#8217; needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually <em>provide</em> a user experience.</p>
<p>As a consequence, I recommend to <strong>make <acronym title="User experience">UX</acronym> a systematic part of the product or component development cycle</strong>, not a separate parallel entity.</p>
<h3>Read also in this series</h3>
<ul>
<li><a href="http://www.gpaumier.org/blog/494_wikimedia-mediawiki-bugs-issues-and-requests/">Wikimedia &amp; MediaWiki bugs, issues and requests.</a></li>
<li><a href="http://www.gpaumier.org/blog/519_scaling-up-software-development-for-wikimedia-websites-human-resources/">Scaling up Software development for Wikimedia websites (Part I: Human resources)</a></li>
<li><a href="http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/">Scaling up Software development for Wikimedia websites (Part II: Tools)</a></li>
</ul>]]></content:encoded>
			<wfw:commentRss>http://www.gpaumier.org/blog/503_wikimedia-user-experience-programs/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->
