Every designer next door an artist?
In my twenties, I wondered how the creative crowd working in design shops, media agencies, the marketing industry, would waste their potential in developing concepts and campaigns for dog food, cheap furniture or flavored water products. Such a waste of talent, I thought, couldn’t they just pursue their inner potential, developing themselves to the next Degas, Valadon, Bosch, O’Keefe, whoever?
I knew better when becoming responsible for a family and found myself in a job environment, exchanging lifetime for cash flow.
Here I came into contact with designers again. They were the guys demanding completely new functionality hard to implement in the last hours before a backend launch. We developers then tried everything implementing the desired features over night, e.g. a completely new sales calculation. In the last minutes before the launch, the release date often suddenly got delayed, sometimes for weeks. I found out it was because for mysterious reasons the design team (as part of marketing) always had a direct line to the CEO and they weren’t content with the design.
We developers started moaning: all the hassle and even hard weekend work for some pixel shifting!
Geek and Glyphs
Those were the days were people like Java Champion (and nowadays Scala–hero) Dick Wall was frequently picked on his design skills by his fellas from the Java Posse podcast (R.I.P.) (see screenshots of jFlubber, later AndroFlubber, a podcast record cutter tool):
Somehow, it felt right: A real hacker would rather write her own parser/lexer over night than dealing with gradients, glyphs and image layers. This state of mind still exists and there are many developers arguing that the only thing that counts is functionality and an “elegant” code base.
Earthquakes at the Hacker’s Seat
Times have changed since then and every progammer (at least a bit interested in what’s going on in the world) must have felt the earthqakes shaking her office seat:
- There was and is dramatic demand for functional programming which already became mainstream, at least since Java 8’s Lambdas and Streams, following Scala and Clojure, following the .NET enhancements and especially F#, following Ruby (to not go behind 2004 and the rise of RoR).
- New ways of thinking about data persistence, resulting in NoSQL databases, different ways of addressing the CAP theorem, and completely different ways of working with persisting state (CQRS, Event Sourcing).
- Also, there’s an ever-increasing demand for asynchronous and/or parallel data processing, both coming from processing “real” big data, IoT as well as from user experience lessons learned.
- JavaScript became ubiquitous through frontend frameworks like jQuery, Scriptacolous or Prototype.js and with Node.js, compatible or depending frameworks, running JS code both on the server and the frontend. It’s used for desktop apps or mobile devices as well as for OS scripting or prototyping. JS frameworks still mushroom and they often address concerns of both designers and developers.
- Mobile devices made dealing with browser incompatibilities worse and changed the way web designers needed to think about creating HTML based user interfaces, resulting in responsive or adaptive designs and frameworks like Bootstrap or Angular.
- The UX wave focussing on the final – here digital – product, resulting in different technical approaches, flat design, linked with Customer Development, later Lean Startup “customer validation” approaches.
- Virtualisation techniques changed the traditional way of software development, delivery and configuration. Software shipment is understood in a holistic way, embracing IT operations, developers and end users (DevOps).
- REST, as an architectural and programming paradigm, brought in a completely new level of ease in connecting independent software systems (most prominent example might be IFTTT, but also check bip.io
“Holy *#!”, you might think, “now he messes up all together!”
But wait.
In fact, all these real disruptive changes are knit together (weird, but derived from a real world example: REST-JSON APIs, delivered on cloud based Docker containers provisioned via Puppet, later Chef, running on Vagrant CoreOS nodes, partially running meteor.js, partially microservices, consumed by responsive web clients built using npm, and implemented with JS’ functional language features) and do address both vertical and horizontal domains.
Consider the HTML 5 standard: It not only takes pure syntax harmonisation into account, but also incorporates JavaScript and addresses programming (e.g. Web Workers, Offline Web Apps, Local Storage) as well as design/UX needs (e.g. Canvas, CSS3, supported media files). Somehow the matters of designers and developers seem to congregate.
Towards #DesOps?
Continuous delivery pipelines and processes can become quite complicated. We face arguments like nobody (perhaps beside “Renaissance Hackers”, the nowadays Da Vincis as coders) could cope even with the specialization needed dealing with all the JavaScript frameworks and that sysadmins and DBAs would never learn to program efficiently. DevOps were in an identity crisis because of a missing standard (manifesto… certifications and merchandising, I guess).
Would that mean we had to squash into our precious build pipelines not only the need for a stable release, but also a stable design? (I can hear them shouting in the office: “Jee – will I have to buy designer clothes?”).
Meet the #Devigner, a new #Deseloper
As stated before we are already in a situation where design concerns are tightly coupled to programming concerns and vice versa.
In the last ~two years we saw an ever-increasing interest at the designers site learning programming. In parallel, since the raise of the smartphone years before, many developers were trying getting into the app business and had to deal with design issues no hacker has seen before.
At the sharp end there are people like Meng To from Canada, now global nomad. He wrote in early 2013 about how designers (NB) should prototype UI designs directly in XCode instead of Photoshop (which was the mobile design tool of the trade before Sketch came).
Meng’s major reasoning was to “push the collaborative work between designers and developers”. Since then, Meng did not stop driving his idea forward: He started designcode.io where developers learn the basics of design and designers learn to code.
“The biggest problem is that designers are completely out of the development process.“
Attending one of Meng’s workshops, I noticed there were roughly 55% developers and 45% designers, so there was a clear demand at both sides and I assume most of Meng’s courses roughly had the same ratio.
Regarding all the in-depth Swift stuff, Meng was supported by André Schneider, an iOS developer who himself descripes as design affected. More than just a statement, André created popping, an example application for understanding animation in iOS and contributes – together with iOS developer James Tang – to Meng’s example iOS app (a Designer News client) and his iOS animation framework Spring (all Java developers shudder because of the name ;).
Animations themselves are another good example of overlapping concerns: Designers need not only to understand the design aspects of animations (long way to subtility), but also the impacts on the technical aspects whereas developers must understand the design intentions to program animations as desired. They are trending not only in native apps, but definitely in web design, too. In fact, following Meng To’s principle, designers should code the animations themselves.
Are you serious: Designers hacking?
DevOps doesn’t mean that DBAs, sysadmins and developers should have both a broad and specialized know-how in all areas. This is a clear misunderstanding in my opinion.
Instead it means that people involved in delivering software are aware of the facets and concerns of all process stages. It doesn’t mean that the DBA actually has to be familiar with the latest machine learning algorithms. She probably won’t be able enhancing the codebase of her algorithm cracking colleague. But she should be aware of the concepts and the difficulties that could affect the entire SW development process. And eventually she could hack herself into machine learning, if really needed. It’s a matter of the mindset: It’s the hacking mindset, well described in Paul Grahams Hackers and Painters article.
DesOps broadens the process and embraces the design and UX aspect. It welcomes designers to put their concerns into the delivery chain and on the other hand demands from them learning as much as being able understanding the other often purely technical concerns.
Developers need to be willing hacking themselves into design and designers into programming. That’s it.
As Meng To and many others found out, a good starting point is prototyping, because there are overlappings of both code and design concerns enabling both designers and developers getting their hands dirty.
Shifting complexity, shifting pixels, shifting minds
I’m aware there are many rants against the full stack developer, mostly arguing fullstack in 2010 meant LAMP and fullstack in 2015 meant everything from virtualization over machine learning, NoSQL, JS frameworks and that there wasn’t any human on earth being capable covering all that. Funny enough, there are comparable statements of the current state of the designer.
So, how could we dare adding design concerns to “the stack”?
In my view, it’s – as ever – a matter of locating complexity in software development and – surprisingly to me – in the design world. Furthermore it’s a matter of how people need and want to work together delivering world class software enriching people’s daily life.
Hello, Design World!
Thinking of establishing trends, I’d like to bring in the following arguments for a mind and complexity shift supporting DesOps:
- The Customer Development/Lean Startup is going to get established in large enterprises. Very early Lean Startup supporter Trevor Owens has even created an Udemy course promoting it with a “Lean Enterprise Certification”. It seems that Christensen’s thoughts have arrived at the large caps. And hey, even product mangers began drawing comics for prototyping! Also Design Thinking seems to make its way. It seems there is a growing need for small interdisciplinary teams creating and evaluating MVPs and working differently compared to established inhouse product lines. These people might need rolling out enough designed enough developed software fast.
- Developers will be unburdened from time consuming tasks that become outdated: The afore mentioned language enhancements, scaffolding/bootstrapping frameworks, the raise of the REST-APIs (and the possibility to outsource complete aspects like e.g. search, business etc.), virtualization, Infrastructure as Code will help to focusing on how the software finally works in the hands and minds of customers. This means more time to connect with design concerns after getting up-to-date.
- Flat design, the familiarity with JavaScript (at least for web designers) and focussed tools like Sketch or Glyphs will help designers to work more efficiently and dive deeper into programming.
From an operational viewpoint it doesn’t matter if you must switch back with your blue/green deployment because the backend has an error in the calculation or the UI is not accepted by the users. But it’ll be good if the problem is understood and addressed by an interdisciplinary team in a process that covers all aspects.
I think, it’s time for a mind shift.
(Hint: Also published on Medium)
Leave a Reply