Category Archives: code

The conversation continues in all the UX forums about unicorns and why don’t more designers write code. I’ve posted on this topic a couple of times here before as well as weighing in in various forums. This was just posted to Quora. See my previous posts on this topic.

Besides the market demand for designers to code, there are two trends that are changing the landscape. They are: 1 -Less variation in the type of cope that is required; and 2 – Maturing evolution of coding tools that are more visual in nature. Both of these reduce the variety of code that one needs to learn in order to be proficient. Both of these have been the holy grail for decades and now seem to be finally coming true.

The promise that a single code language would emerge to rule them all, relieving everyone of needing to relearn how to code has been happening forever. The identify of the super final code style changes every year two, forcing coders to relearn over and over, repeatedly. Reality is that it has exacerbated the problem was is supposed to solve. Some promise. Those unaware of this phenomenon have lived a sheltered life, probably fairly new to IT or spent their whole careerer within a single organization or industry segment.

As one starting out as an industrial designer, turned systems analyst / UX designer / IA / business process engineer, i have learned to use a great many tools, digital and physical. It stands out that most physical power tools still work the same way to today that they did twenty years ago. Being away for a while, or dividing my attention with other tasks carries no penalty. I can pick up a torch after ten years and weld steel same as ever. So not true with software. So not true.

And if you are in enterprise IT, it is even worse. Most large organizations have a variety of new and desperately old systems written at different times when different languages were popular. This can make instant beginners out of seasoned experts. They will be at any given moment working on migrating the menagerie to the latest architecture. It is a huge task, taking months to years and sometimes feels almost impossible as the target continues to move, sometimes faster than they can change. Anyone changing organizations frequently, or consulting, as many do these days, will see a somewhat different variety of this in each location. But it is common across all large enterprises.

The good news is that much of this finally getting better. As apps move to the cloud, the browser-based UI is clearly dominant. More of the variation these days are therefore subsets, plug-ins, rather than entirely new disparate sets of tools. Even so, there is plenty to keep up on if one is to try to be a good code jockey. Do you do Drupal? Or Ruby? or dot.Net? Just wondering.

There is also more fulfillment lately on the long-standing promise of visual tools. Actually being able to define the look and behavior visually and have the tool create the necessary code is closer to reality than ever before. it is worth noting that the process of building a visual prototype to be coded offshore can have a similar practical impact on the design task. Whether the code is generated, by in-house developers, off-shore, or by an app, having an accurate visual method in which to articulate the design (as in NOT PhotoShop!) will enable the UX designer to focus more attention on the user experience while being assured of feasibility.

Meanwhile UX research and design methods and patterns are changing faster than ever. Lean start-up, customer experience, and product management is hot, like Six Sigma and Process engineering were a few years back. All of these demand focused attention. The answer is of course is quite simple. One must simply maintain a laser sharp focus on everything. 😉