<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
    <channel>
    <title>UXblog</title>
    <link>http://ampli2de.com/uxblog/</link>
    <description>Random UX thoughs</description>
    <language>en-us</language>           
    <generator>Nucleus CMS v3.50</generator>
    <copyright>&#169;</copyright>             
    <category>Weblog</category>
    <docs>http://backend.userland.com/rss</docs>
    <image>
        <url>http://ampli2de.com/uxblog//nucleus/nucleus2.gif</url>
        <title>UXblog</title>
        <link>http://ampli2de.com/uxblog/</link>
    </image>
    <item>
    <title>Why Sr. Management (Eventually) Hates UX: #1</title>
    <link>xml-rss2.php?itemid=33</link>
    <description><![CDATA[The more I work on large projects, the more I realize that there is a point in each of them where a rift is created between the priorities of the senior management team and those of the UX team. Let's think about the typical timeline of how this plays out: Initially, we present our past work, our methodology (process) and the advantages of having a UX team on board. We show them user research, IA and design documentation, previous prototypes, finished designs and we hope that something will resonate with them that will persuade them to hire us. We'd like it to be something we've done in the past or the methodology we're employing, but as the project goes on, we realize that it was something else.<br />
<br />
<img src="http://ampli2de.com/img/puppet.png" style="width: 204px; height: 129px; padding-top: 3px; padding-right: 15px; padding-bottom: 6px; border: 0px; float: left;" alt="" /> Typically (and I say typically because of my own experiences, I am sure things are slowly shifting), senior management is intrigued by the idea of having a UX team on their project mainly because one thing only: risk management considerations. I know, this sounds cold, but it's at least a large component of the truth. I've had this discussion as part of lessons learned / post-mortems of many projects that I've been involved with, and without exception, that was the main reason why a UX team was initially considered for the project. To expand a little further, the senior management team sees having a UX team on large projects as an insurance policy that states that by employing UCD methodologies the client will be part of the design proces. As a result, when UAT comes around, it will be very difficult for the client to reject a design that they were at least partially responsible for. All very valid points. <br />
<br />
However, at some point in the process (in my experience this occurred anywhere between right after the end-user research stage, to the end of the high-fidelity prototyping stage), senior management starts to get impatient... Even though we are on track as far as the project plan is concerned, and even though the clients love the idea that we are constantly picking their brains in regards to how to redesign their product, senior management teams tend to get unhappy about the things that we uncover. So in this series of posts about why the senior management team hates UX, this is the first item i want to talk about...For some reason, the senior management team will always assume that most of the things we will uncover are related to layout, design and maybe in some cases workflow. It turns out that on top of creating a better layout and a better workflow, we also tend to uncover other things like new features that are very important to the client and no one in the functional requirements team bothered to explain to them and/or major process improvements that positively affect the user experience.<br />
<br />
These of course, are double edged swords. On one hand, senior management should be very happy because making these changes/additions guarantees that the client will be happy with the final product. But on the other hand, spending the time to define, analyze, prototype, develop and these new features/changes does require additional human and financial resources. Sadly, this typically results in a heated argument between myself as UX Manager/Lead and my project director regarding how this came up and why I didn't immediately shut down those discussions with client. Of course, long explanations and justifications ensue.<br />
<br />
Don't get me wrong, I'm not asking my clients or my UX teams to go out there and ask what else they want in their applications, most of the time these features happen to be things that are making the client's life much easier and no one bothered to present to them as options. They are also critical elements, not simple cosmetic additions. But in the eyes of senior management, these are new things that were not planned for and more importantly budgeted for... As much as I'd like to question how the budgeting was made not allowing any kind of on-the-fly changes, I know I would be out of line to do so. But nonetheless, the argument still stands. Call it 'padding', call it whatever you want, when dealing with large projects, the requirements that were initially defined will have to be refined during the work that the UX team is doing. Also, the work of the UX team will minimize the requests coming out of UAT so any resources available for post UAT should be easily shifted to assist in making these on-the-fly changes.  <br />
I am trying to make all this very clear during my interview and the initial meetings with my project director, but most of the time, this seems to be just polite talk.<br />
<br />
These days, I am shifting the way I approach this conundrum. I tell those who are hiring me that they should treat me as working for the client, not for the hiring company. This way, all of the objections that are being raised have to be considered as if a client made them, and not someone who is hierarchically lower than the senior management team and whose objections can be easily refuted. I also happen to be the kind of UX practitioner that will not put my name down on a deliverable if I don't think the work has been executed ethically and up to the standards that all parties expect.<br />
<br />
What are your thoughts on this? Anyone else out there encounter similar situations?]]></description>
    <category>user experience</category>
    <comments>xml-rss2.php?itemid=33</comments>
    <pubDate>Wed, 3 Mar 2010 14:04:00 -0500</pubDate>
</item><item>
    <title>Is Public Driven Design (PDD) the New UCD?</title>
    <link>xml-rss2.php?itemid=25</link>
    <description><![CDATA[Last week I stayed up until 3:00AM EST to watch the live feed of the Davos World Economic Forum <a href="http://bit.ly/cOW7oU" class="details" target="_new">Social Media Panel</a>, hoping that one of the speakers will describe the future impact of Social Media in all aspects of product design. The first guest speaker, <a href="http://blogs.forrester.com/colony/2009/03/my-session-at-d.html" class="details" target="_new">George F. Colony</a>, CEO of Forrester Research, provided me with a good starting point. He introduced the concept of 'Social Sigma', by making a parallel with Six Sigma and explaining that in the near future all companies will have to probe  social networking and social media sites during the process of designing their products.<br />
<br />
Don't get me wrong, this idea has been around for a while, but in a different form. Information Architecture, Design or UX practitioners following UCD (User Centered Design) Methodologies made of point of ASKING a sample of the product's end-user population about how to design a product. Virtually every site and consumer brand out there ASKS for feedback on their presence and products. This paradigm included ideation about business/technology requirements as well as user interface (ease-of-use, simplicity, recognition, etc.), and in most cases, it worked very well. End user research, IA, interaction design, prototyping, usability testing, all of these minimized the risk and in the end the product was relatively close to what the clients wanted. But...Fast forward to 2010. With the proliferation of social networking and social media, the customers (typically the public at large) are moving beyond expecting to be asked about a future product, and actually DEMANDING that the product includes certain features. The process is quite different than User Centered Design, so I will call it Public Driven Design (PDD). Instead of ASKING a subset of end-users about the product, we can listen, analyze and visualize the market/media beat to uncover the public's expectations of future products featuresets. Social networking tools now allow users to DREAM/DEMAND (and consequently DEFINE) where the product is going. Function, design, technology... all of these elements can be user driven if the right social media aggregation tools and competent UX personnel are used. <br />
I know that by this point, most of you have heard some flavour of this exact message. But other than a few costly examples, to my knowledge, there are no small budget social networking driven product ideation campaigns that have revolutionized a well known consumer product. <br />
<br />
Here's my take on what happens when PDD is being ignored. After much anticipation and fanfare, Steve Jobs finally introduced Apple's new creation, the iPad. If we are to believe the reaction on the web, by the time it was all said and done, Apple seems to have hit well below expectations. In this case, rather than letting the customers define the product, Apple chose to use the old silo approach (and who blames them, they've been hitting home runs with their industrial product design for the past decade). However, in this case, things were a little different as social media is now part of the mainstream. Everyone online started dreaming about the features and capabilities of the new tablet (the appearance of which was leaked to the media well before the January 27 announcement). Based on the latest gadgets and the evolution of available technological standards, various social media / social networking entities started putting together the 'expected' feature list of the iPad. Needless to say, things like multitasking and Flash support were on everyone's mind, along with handwriting recognition, decent battery life, video camera, multiple connectivity options etc. Well, it turns out that none of the above are available, at least in the first generation of the iPad and as such, the product itself feels like a major  disappointment. <br />
<br />
Now let me ask you this: Why not let the consumers decide on the most desirable feature set for the iPad (they did this anyway whether they wanted it or now) and start your development once you've identified the home-run features of your product? Why not leak the platform intentionally and let the world share their opinion about what they are willing to buy? Personally, I would've spent 1K instead of $499 on an iPad if it had all of the missing features mentioned above. Since it doesn't, I've bought myself a more expensive 13.1' laptop (Sony Vaio Z820D) as my portable device of choice for the next couple of years even though I was hoping that the iPad will turn out to be something I wanted.<br />
<br />
And to conclude, here's a funny little YouTube video that illustrates a funny but true reaction to the iPad:<br />
<br />
<object width="528" height="350"><param name="movie" value="http://www.youtube.com/v/lQnT0zp8Ya4&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/lQnT0zp8Ya4&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="528" height="350"></embed></object>]]></description>
    <category>community</category>
    <comments>xml-rss2.php?itemid=25</comments>
    <pubDate>Mon, 8 Feb 2010 11:54:00 -0500</pubDate>
</item><item>
    <title>Say &apos;Hello!&apos; to the New Decade: Ampli2de Brand v3.0</title>
    <link>xml-rss2.php?itemid=23</link>
    <description><![CDATA[It's hard to believe that it's been 10 years since Ampli2de was born in 1999, back home in Transylvania, as a project that started out of boredom more than anything else. As I was looking to do something productive during my first summer after university, I came up with a name (the company used to be called Ampli2de Studios S.R.L.) and I ended up spending a few hours one night putting up some posters all over town about our new web design startup. All it contained was the name, the number, and the logo (the first of the three pictures after the break). <br />
<br />
<img src="http://ampli2de.com/img/logos.jpg" style="width: 530px; height: 100px; border-top: 1px solid #CCCCCC; border-bottom: 1px solid #CCCCCC;" /><br />
The next day my cellphone started ringing and it never really stopped afterwards, until 2003, when I returned to Canada full-time and I've decided to continue the venture here, mostly on a part-time basis, as my UX professional career started to take off in the corporate world. At that point, Ampli2de Communications Inc. was born, and our second brand identity was launched. We liked it a lot at the time, and more than anything, it signified a new beginning in a world that is quite different than the one I grew up in.<br />
<br />
Fast forward to 2009, when after a successful corporate career that included project work in the most vibrant UX cities in North America, I've decided to go back to my roots and dedicate (most of) my time to the project closest to my heart. This is why I felt we needed a new brand identity, and designed version 3.0.<br />
<br />
I've received some interesting feedback from my tweeps about the logo, and I'm happy to say it is almost entirely positive (you can't please everyone right? O). We feel it's definitely a step in the right direction, and we cannot wait to continue working tirelessly for our UX/usability clients. <br />
<br />
Cheers to the new decade, and to version 3.0.]]></description>
    <category>branding</category>
    <comments>xml-rss2.php?itemid=23</comments>
    <pubDate>Fri, 11 Dec 2009 23:34:00 -0500</pubDate>
</item><item>
    <title>Wireframes Basics, the Ampli2de Way...</title>
    <link>xml-rss2.php?itemid=22</link>
    <description><![CDATA[The first mistake made out there is assuming that wireframes are primarily a design deliverable rather than an information architecture (IA) deliverable. The right interpretation should be self-explanatory. I personally use wireframes to demonstrate information, task flow and page flow rather than branding or graphics design. However, the notion of a wireframe has been expanded lately to include everything from physical hand-drawn paper screen mockups to high-fidelity, fully branded screen designs. This being said, my personal preference is somewhere in the middle as I prefer to use specialized applications to create them as a basis of discussion of content and overall structure rather than visual display.<br />
<br />
If anyone's ever looked at a typical wireframe (and i say 'typical' very loosely as everyone personalizes the way they create them), you will notice that it consists of a collection of boxes, controls and annotations that make up the skeleton of an application screen. Each box may be an image, a section, a cell or a placeholder for application content.<br />
<br />
When presenting screen design in the form of wireframes, application controls are also included. For example, in the case of a wireframe created for a web application, representations corresponding to HTML form controls will be added to the screen design in order to make the wireframe appear as an early drawing of the final product.Bubbles or baloons are also overlapped over the wireframe elements in order to highlight additional information about the screen design. I use numbered baloons to highlight a couple of concepts. The first one is the importance of the screen component (I rank screen components as high, medium or low priority). The second one is a clickpath, a concept that allows the user to see what happens when clicking on select screen elements. Clickpaths are only shown when making major navigation decisions rather than adding bubbles or baloons for every link, button and event associated with screen components. <br />
<br />
A new addition to my wireframe designs are multi-layer options. Rather than recreating the same wireframe multiple times to show changes within a layer (as a result of AJAX calls for example), I simply add the layer views as a separate page of the wireframe. That way, if the main wireframe elements change, I will not have to update every single page view option. <br />
<br />
All of these wireframe elements will create a set of screens, however, when presenting them to a client I also like to include the task flow or the sitemap. In some instances (large clients) I have even printed out a large poster containing very small versions of each page so that the client can visually follow the flow and the wireframe at the same time. This is very tricky for large applications and is more useful once the flow and the wireframe structure is relatively stable.]]></description>
    <category>tools</category>
    <comments>xml-rss2.php?itemid=22</comments>
    <pubDate>Mon, 7 Dec 2009 23:18:00 -0500</pubDate>
</item><item>
    <title>Elliptic Labs Makes Touchless UI a Reality</title>
    <link>xml-rss2.php?itemid=21</link>
    <description><![CDATA[The guys at Elliptic Labs have finally managed to do what Zaphod Beeblebrox and Tom Cruise's character in Minority Report have attempted to do for a while: use a touchless, gesture-based, user interface that doesn't require sensors installed on the hand. According to the Elliptic Labs website, "the hardware is based on standard components only, similar to those in a mobile phone. The system can run on the CPU and power in most usual consumer electronic devices. It can be embedded into any electronic device, including hand held ones." <br />
<br />
However, we've seen something similar to this before in the form of electrostatic UI's, which also happen to be touchless. However, Elliptic are the only ones that created sensor hardware that is based on standard components, and also used a form factor that is more portable and usable than our favourite Northwestern students.]]></description>
    <category>research</category>
    <comments>xml-rss2.php?itemid=21</comments>
    <pubDate>Wed, 9 Sep 2009 23:12:00 -0400</pubDate>
</item><item>
    <title>Moblin 2.0: A Truly Functional UI For Portables</title>
    <link>xml-rss2.php?itemid=19</link>
    <description><![CDATA[While innovation in the realm of portable (i.e. netbooks) and mobile user interfaces shifted towards speed, functionality and support for a variety of standards and hardware technologies, Intel's new version of its Linux-based netbook UI has truly taken a step forward in terms of usability and user experience.<br />
<br />
What's different about Moblin 2.0 ? Well, it's a bit of a departure from the usual desktop paradigm as the UI is organized into elegant tabbed panels and application "zones" (think virtual desktops with improved UX). The home screen interface is also quite functional, showing the usual tasks list, calendar and application shortcuts, as wells as other integrated widgets (eg. Twitter). Quite a feast for the UX eyes.<br />
Ars Technica <a href="http://arstechnica.com/open-source/reviews/2009/05/hands-on-intel-brings-rich-ui-to-moblin-linux-platform.ars" class="details" target="_new">published an in-depth look at Moblin 2.0</a> and its amazing integration of features and user experience, which begs the question: is this the best consumer UI out there ? I would argue that it's between Moblin 2.0, Palm's new WebOS UI , Apple's UIs on various platforms and MS Vista. And yes, I'm totally joking about Vista :O)]]></description>
    <category>research</category>
    <comments>xml-rss2.php?itemid=19</comments>
    <pubDate>Tue, 9 Jun 2009 23:04:00 -0400</pubDate>
</item><item>
    <title>Medium Display Panel Sizes No Longer Get The Love</title>
    <link>xml-rss2.php?itemid=17</link>
    <description><![CDATA[Looking at the recent evolution of user interfaces, there seems to be a consistent trend of making things smaller or bigger than the typical dimensions of desktop/laptop screens, while the usual (let's call it 'medium' for the sake of this argument) size seems to fall out of grace with computing platform manufacturers.<br />
<br />
As examples, everyone is mesmerized by the iPhone and similar portable (and consequently small) media players. eBook readers, netbooks, portable gaming systems, portable medical systems, etc. seem to converge towards convenience and ease of use, which means a small physical size. But while making things more compact has been the typical direction of human technology for obvious reasons, making things larger is in a way a major change of direction, unless we take a closer look at the more recent mainstream advancements in UI paradigms. Touchscreens, multi-touch devices, electrostatic user interfaces, they all require a fairly realistic motion in terms of scale, so moving your fingers or limbs on or above a large surface but responding on a small screen is very counterintuitive. Even brain user interfaces (BUIs) require a large display to project the motion sensed by electrical sensors.<br />
As a result, things like the Microsoft Surface and other similar technologies, multitouch panels, etc. are typically displayed on larger devices where zooming and providing a lot of information at the same time is very important. So small is in, big is in, but medium seems to be a bit forgotten. And since i don't see myself owning a big a** table or a large multitouch panel anytime soon given the current price tags, i wonder what the near future holds for consumers with average buying power looking to stay on pace with the technology. Any thoughts ?]]></description>
    <category>user experience</category>
    <comments>xml-rss2.php?itemid=17</comments>
    <pubDate>Mon, 25 May 2009 22:38:00 -0400</pubDate>
</item><item>
    <title>Starting Out as a UX Practitioner in This Economy</title>
    <link>xml-rss2.php?itemid=15</link>
    <description><![CDATA[A lot of young people (either still in university or recently graduated) ask me about the prospect of getting a UX job in Ottawa, especially in the current state of the economy and the rising number of unemployed technology workers competing for jobs. While I don't monitor the job sites frequently, my answer to them is that I personally never really had a problem being employed, either as an independent or as a full-time employee, so as long as you put in the time to acquire the necessary technical/business/artistic skills required, I don't really see why you wouldn't be in good shape.<br />
<br />
However, when i do do a quick scan on the typical job sites (Workopolis, Monster, JobBoom etc.) dealing with the National Capital Region market, the most I've seen is a couple of postings at a time. Traditionally, cities like Toronto, Vancouver and Montreal tend to have the bulk of the Canadian UX market, but I still wondered whether I was doing a real search or I was just scratching the surface. Another quick look in the careers sections within the websites of two well known Ottawa interactive agencies (Fuel Industries and Teknision) reveals at least about 10 other UX related jobs, but they are typically high end (Flash/Flex, UX Architect) requiring at least 3-5 years experience. The jobs catering to junior resources still seemed a bit more scarce.<br />
Which begs the question, if you are like one of these guys, starting out with basic UX knowledge and have a relatively skinny portfolio, while reading some books on design, marketing, usability, user experience, etc., and slowly rebranding yourself into a UX type, what should you do ? I would almost venture to say, if you can't make it into an established company like the two above, start out with a couple of contracts (dare I say within the government :O), get some exposure to usability, accessibility, CLF 2, etc., network within the local CapCHI/Meetup/Social media scene and work your way from there. And keep reading and experimenting on your laptop, sooner or later your time will come.<br />
<br />
Anyone else out there have other suggestions ?]]></description>
    <category>community</category>
    <comments>xml-rss2.php?itemid=15</comments>
    <pubDate>Mon, 27 Apr 2009 22:34:00 -0400</pubDate>
</item><item>
    <title>CanUX 2008 brings Canadian content to the UX world</title>
    <link>xml-rss2.php?itemid=14</link>
    <description><![CDATA[  A day after World Usability Day (Nov 13), I am heading out to the Rockies for CanUX 2008, an annual event that has become a staple on my conference circuit. Organized by the guys at nForm (Jess McMullin, Gene Smith and Co.), the conference has great workshops and well-respected speakers from the UX world.<br />
<br />
This year, the conference is highlighted by Dave Gray (XPATH), Brandon Schauer (Adaptive Path), Luke Wrobleski (Yahoo!, LukeW Designs) and Dennis Wixon (Microsoft Surface). And being in Banff, this will probably also be my first snowboarding outing of the year. Can't wait.]]></description>
    <category>conference</category>
    <comments>xml-rss2.php?itemid=14</comments>
    <pubDate>Fri, 14 Nov 2008 22:30:00 -0500</pubDate>
</item><item>
    <title>Brain User Interfaces Are a Reality</title>
    <link>xml-rss2.php?itemid=13</link>
    <description><![CDATA[When dealing with the future of user interfaces, most people think in terms of multi-touch, interpretations of web 3.0, eye trackers, etc. And while it all may very well happen that way, there is also another palpable possibility, brain-controlled user interfaces (let's call them BUIs for the sake of this post). <br />
<br />
Researchers at the University of Pittsburgh School of Medicine have managed to connect a monkey's primary motor cortex to a robot arm with astounding results (read the entire article and see the video <a href="http://news.bbc.co.uk/2/hi/science/nature/7423184.stm" class="details" target="_new">here</a>). Yet for some reason, this has received little attention from the UI/UX world and has been singled out as a purely medical breakthrough.<br />
<br />
Let's face it, if a wireless solution can be implemented, we might very well be looking at the future of user interfaces. ]]></description>
    <category>research</category>
    <comments>xml-rss2.php?itemid=13</comments>
    <pubDate>Mon, 16 Jun 2008 21:52:00 -0400</pubDate>
</item>
  </channel>
</rss>