It recently occurred to me that not one of the dozens and dozens of user interfaces I’ve worked on over the years, had the same methodology/lifecycle. Many of those were results of the environments under which they were constructed: startup, BIG company, government contract, side-project, open-source, freelance, etc. But the technology also played a part in choosing the methodology we used.
Consider the evolution of UI technology for a moment. Back in the early days of unix/x-windows, UI development was a grind. It wasn’t easy to relocate controls and re-organize interactions. Because of that, we were forced to first spend some time with a napkin and a sharpie, and run that napkin around to get feedback, etc. The “UX” cycle was born.
Then came along things like Visual Basic/C++ and WYSIWIG development. The UI design was literally the application. Drag a button here. Double click. Add some logic. Presto, instant prototype… and application. You could immediately get feedback on the look and feel, etc. It was easy to relocate, reorganize things and react to user feedback. What happened to the “UX” cycle? It collapsed into the development cycle. The discipline wasn’t lost, it was just done differently, using the same tools/framework used for development.
In such a world, again — you wanted to make sure you got it right, because adjustments were costly. Fortunately, in the meantime the UX discipline and their tools had advanced. It wasn’t just about information display, it was about optimizing the interactions. The tools were able to not only play with look, but they could focus on and mock out feel. We could do a full UX design cycle before any code was written. Way cool. Once blessed, the design is/was handed off to the development team, and implementation began.
I liken this to the shift that took place years ago for application design. We used to sit down and draw out the application architecture and the design before coding: class hierarchies, sequence diagrams, etc. (Rational Rose and UML anyone?). But once the IDE’s advanced enough, it became faster to code the design than to draw it out. The disciplines of architecture and design didn’t go away, they are just done differently now.
Likewise with UX. User experience and design are still of paramount importance. And that needs to include user research, coordination with marketing, etc. But can we change the toolset at this point, so the design and development can be unified as one? If so, imagine the smoothed, accelerated design->development->delivery (repeat) process we could construct!
For an innovative company like ours, that depends heavily on time-to-market, that accelerated process is worth a ton. We’ll pay extra to get resources that can bridge that gap between UX and development, and play in both worlds. (Provided we don’t need to sacrifice on either!)
On that note, if you think you match that persona. Let me know. We have a spot for you!
And if you are a UXer, it might be worth playing around with angular and bootstrap to see how easy things have become. We don’t mind on the job training!
|Reference:||The Life(Cycles) of UX/UI Development from our JCG partner Brian ONeill at the Brian ONeill’s Blog blog.|
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.