The Design Professions' Digital Transformation

Designers have worked in digital with digital tools for decades. Indeed, but that was only the first chapter. Digital transformation circumscribes the move from value creation through physical means or touch-points only to either a mix of physical and digital or to pure digital.

Mainstream yet?

In fact, management consulting and accounting firms did hop on the Digital Transformation bandwagon a little while ago. Note that these companies are inherently business consulting and accounting firms but now (want to) help (industrial) companies to Go Digital.

I bring this up for a couple of reasons.

Firstly, you can see how mainstream the topic Digital Transformation has become. Digital has moved passed the early adopters, innovators and early part of the early majority to ignite the interest of early and late majority (in terms of Geoffrey Moore's Crossing The Chasm).

Secondly, it indicates that Digital Transformation is not just an IT or design thing to try out. I think most people understand now that Digital touches every bit of a companies' touch-points, either internally or externally (e.g. with B2C customers).

As an aside, I wonder why companies (want to) have breakfast, lunch and dinner (aka the digital expertise) prepared by supermarket directors (aka the management and accounting firms) and not by real chefs (aka real nerds, tech people, agencies)?

But how does the design profession fare in the face of everything else being transformed?

From design to code and back to design

The (digital) transformation in design

I am strongly convinced that the market drives everything. The underlying fundamental is of course a human desire, want or need. The result of a growing market and profession going mainstream (if you so want), is that the profession itself, its expertise, processes as well as tools improve and evolve, or transform:

• Expertise
• Processes
• Tools

Either of the above does influence each other. But let's dig deeper and expose each a little more.

Expertise

In order to alter or influence process and develop new tools, an understanding for the problem or task at hand is necessary. Human curiosity drives expertise, which in turn brings products and services to market, which in turn again helps expertise, processes and tools in regard to solving new or old problems.

I do not share the opinion that stellar UX work is a commodity."

As the market for the design profession grows, a person's expertise extends, deepens and evolves. Part of this evolution in regard to digital transformation is the designers' technical expertise.

Growing interest for User Experience

I do not share the opinion that stellar UX work is a commodity, easy to get and to buy at every corner. Yes, the entry point of UX is moving upstream but so does extend the upper bound of what I just called stellar UX (work). Alas, also the expertise level moves upward which is what I like to circumscribe as part of the design professions' digital transformation.

But what does it imply to have deep know-how from an experience design perspective? It may be particular deep knowledge about a certain domain or breath of knowledge across various domains. What the transformation now made certain is that the knowledge comes with a technical understanding (as well as systems thinking) for one or various expert domains. What makes the designs' transformation so profound is the broader level of technical understanding. I would not say that it implies an engineering mindset but it does imply an ability to put on another hat (a technical perhaps), and think out of the box (in regard to design).

Processes

Generally speaking, throughout the experience or software design process, the closer one gets to technical development the more important it becomes to align with engineering, apparently. A decade ago it was more like a black-and-white separation: the design team would either hand over Photoshop combs (where engineering would slice and dice) or exports thereof.

It was not just a matter of a deliverable or receivable but also one of process. Both design and engineering teams used a waterfall-like process structure (of course, with a subset of the markets teams already using or venturing out into agile).

Fast forward to today.

Design and engineering teams work side by side, usually adhering to the agile manifesto whereby frequent iteration is the norm. Design teams are about one or two sprints/cycles ahead of engineering, frequently iterating on its own based on incoming feedback. The change in thinking and doing was partly driven by an even stronger focus on users. More importantly though, it was inspired or driven by Lean UX and then Design Sprints which themselves took inspiration from Lean Startup (read engineering processes).

Process is really not a black-and-white game with two options. Everyone on a team brings her or his set of experiences (the grayscale), tips and tricks to the team and process. Tools and process go hand in hand of course, they influence each other.

The aspect that I think will change the process within design teams within the next 2-3 years – I think – are version control, libraries and even stronger systems and modularity-thinking.

They were partly made possible by the ongoing mainstream trend to using vector-based data for design. Although px-based data can technically work the same way, however, it just does not fly well due to certain constraints. However though, due to faster and faster broadband connections, we might see similar trends in a few years.

Tools

Digital tools are certainly not the start of an Experience Design process, but they influence the overall process and – of course – even expertise, extensively. Tools enable us designers to collaborate in many new ways. User research can be done remotely, visual design tools allow us to collaborate across continents and departments. This is only possible because of technology at the root.

10 years ago we still used shared hard drives or sent files via email to collaborate (on design). Then came online storage like Drive and Dropbox as well as the likes of Invision. But now, we are on the verge of yet another transformation of the design tool set: Version control that designers will definitely use (sorry, PS Version Cue).

Version control for collaboration

And yet again it evolves around Sketch. In the prior article Design is Code, Code is Design I have outlined how Sketch's new open file format will revolutionise the collaboration between departments. If you think that the human-readable format is just some other open format, I strongly urge you to go and read it.

What the format does allow for is version control and libraries. Well, technically speaking, the creators of Sketch could provide both as proprietary features/apps. But open access is what makes it exciting in the first place (think Open Source). Next to the very benefits of version control itself (read a primer and what it may mean for design here), it therefore allows for a very tight integration between engineering and design. In fact, engineering has been using version control for decades.

Open access is what makes it exciting in the first place

It's early days for version control in design but the benefits are thorough: clever tracking of all work and a holistic understanding of what was done when and why, by whom. Engineering members will send you a smiley, each time you check-in work. Besides, it will improve internal communication and understanding, next to faster cycles.

Please have a look at the bare-bones approach here (the more technical) or go and check out AbstractApp.

Libraries

Now for libraries. You guessed it right. Engineers have been using these too for decades. What's the benefit? Once a library has been written for a certain purpose, say, importing contacts to a web app (backend in NodeJS), others can use library instead of rewriting the same.

With Sketch libraries you can now finally manage assets and components across teams and projects. Gone are the days where you would have to copy and paste every other component from file to file. Imagine for instance that your favorite Bootstrap UI kit just got an update: if you would now work with libraries, in a few clicks your current working file and all assets reflect the updated UI kit or its components.

Conclusion

Design takes its influence from a plethora of fields, areas of expertise and experiences.

As I tried to show above, neither expertise, nor process, nor tools stand for itself, nor is transformed in a vacuum. All aspects are strongly intertwined and result in a profession that is moving and transforming.

The technical nuances are slowly coming to light (for those who want to see them). The beauty though is that in the face of its transformation, it is not "in your face". The technical aspects of this change are hidden for the glamorous and proven sake of user-centeredness and simplicity.

If you like what you have read, please give the article a like, much appreciated.

A Thank you goes to Mathieu of Kactus.io for reading a draft.