Innovation through UX

This blog post by Jen has attracted my attention... I will probably state the obvious the same way Matt is good at doing (so he claims)... ;-)

Jen's post makes it obvious to me that the UX phase in a project might very well be the "easy" way to innovate in a project.  By comparison to a project without UX.  Here is why. 

First, software engineering people are mostly concerned about construction of the software.  Their focus is delivering the code.   

Second, software engineering people are... software people., this is their expertise. Many of these guys will be concerned by usability or innovation but this is not their primary focus.  They are first and foremost experts at software technology, tools, languages, software design patterns, mostly software creation centric stuff... (I believe for most of them at least)

Our UX team is by contrast much more in touch with the research world, it seems to be a natural aspect of their role to be aware of what is out there so they can integrate these academic projects into a real projects. 

In the example brought up by Jen it is clear that a software engineer could have thought of the multi-vibration thing but probably without awareness of the research project done in a particular university.  It would probably be a "wouldn't it be cool" kind of enlightment.  

As valid as this "wouldn't it be cool" idea might be it would lack the link to the academic research and would probably be much harder to sell if at all possible.

 

    

It's got to hurt....

Yesterday a citizen from Gatineau was publishing an comment in LeDroit newspaper about innovation.

He was talking about the how messy and broken our roads are by referring to their numerous holes they have (nid de poule in French). He was somewhat pissed at seeing how the blue collar can mow lawn and do all sorts of tasks with efficiency by using various smart tools and comparing this to how poor they do the job at fixing the roads.

He was, in other words, asking them to innovate and fix this problem once for all.

That made me realize that it's got to hurt for one to innovate. The cities by sending a team of 5 with one rake and one shovel to fix these holes are not creating a context that will trigger innovation.

Similarly, I got a urge to improve (and maybe innovate) this week following a rare but terribly bad project customer survey. That whipped me to ensure we put in place the measures to avoid these problems in the future - even if they are not common. This is my role after all.

When I look at the feeling I got this week related to that, it seems more and more obvious to me that to improve "it's got to hurt", and believe me it hurt.

Innovation does not imply improvement, nor does improvement impliles innovation. It seems however, that adding some pain in the mix you might get one or the other, and if you have the good people in place, you may get both.