UI Design in 2018
April 20th, 2018The world is moving with lightning speed in developing and refining processes and tools for things like deploying software essentially in real-time—the devops revolution, if you will. And great progress has also been made in areas such as building and modularizing and optimizing complex applications, or designing micro-service architectures. But such innovations do not seem to have reached the UI design world.
UI design, obviously, refers to the design of user interfaces, including both their visual and interactive/behavioral aspects. I am not talking about “graphic design”, of the sort involved in designing brochures, or posters, or even cool websites, for example. (The conflating of “graphic design” and “UI design” lies at the root of a lot of confusion and inefficiency in the design area. A lot of graphic designers think their great graphics skills automatically make them qualified UI designers, for example. Even otherwise knowledgeable executives hire graphic design teams when what they really wanted was UI designers.)
The problems with the UI design process as typically implemented are legion. Many designers, especially external ones, try to multi-task across projects, and so they never really develop the domain knowledge they would need to do a good job. Many designers coming from a graphics perspective view their work as being to create beautiful static designs, so they fail to think about (or document) how things will work, such as navigation. In the same spirit, many designers view each screen as a new “brochure” to let loose with the full range of their creative impulses on.
It’s also unfortunately quite rare to see designers who consider, or are open to feedback, on implementability, or who will even re-use UI paradigms that would save engineering time as well as make the user experience more uniform. The overwhelming majority of designers work in a ghetto of design-specific tools, giving rise to a huge amount of friction and conversion costs in realizing their designs in code. Recently they probably also use design-specific workflow tools, meaning everyone has yet another tool and login and process to remember and learn how to use. The majority of designers, it is safe to say, don’t really “get” agile or MVP. It’s common for them to view their designs as finished, pixel-perfect masterpieces.
What is even more alarming is the creeping takeover of the product management process by some over-ambitious designers, who claim that only they truly understand the user, and truly know what the user wants. They move beyond consulting on features to trying to take ownership of feature decisions. The irony of course is that in too many cases they actually understand the user more poorly than product managers, or product owners, or business folks, or even developers.
But wait. We have to have designs to look at and talk about and tweak so we know what we’re going to implement, right? And those designs have be conveyed in visual form somehow—like in Photoshop, right? And “management” wants to look at those designs, right?. And those designs also have to be shared somehow—like with some cloud-based design workflow system, right? That is the mentality we have grown to take for granted, and is what has led us into a design process which is heavily siloed in terms of tools and processes.
As a rough analogy, imagine that every computer program was mandated to first go through a “program design” phase, where the structure of the program—files, routines, classes, or even variables—was designed by a separate person or team, who were not themselves engineers but “program designers”, using a separate set of program design tools that had nothing to do with the technology that would eventually be used to implement the feature. Imagine that those program designs, using such program design tools, and shared using some program design cloud feature, were discussed and iterated on. And that only when the program design was finalized would a programmer then take the program design and convert it into an actual program, with very little of the design being directly re-usable in or convertible into the implementation. If during the course of implementation, it turned out that the design needed to be revised, of course only the most disciplined teams would take the time to go back and update the program design. So as a “bonus” for having this separate program design step, we would also end up with out-of-date program designs the first moment the design changed due to issues coming up during implementation, which in the best case would be a source of confusion. Imagine the inefficiencies inherent in such an approach.
I am not saying that we do not need to design; in the example I just gave, in fact time spent doing program design is often very well spent. What I am saying is that such program design, or UI design, should not occur in a vacuum, by a separate team of “experts”, who hand off their designs for implementation by someone else. The design work should be part and parcel of the development process, carried out by developers, in the broad sense. Others can consult and give input.
People talk about the need for UI prototypes and mock-ups, and systems for creating them. But actually, we already have a system for UI prototypes and mock-ups: it’s called HTML and CSS. Doing prototypes and mock-ups in HTML and CSS has huge advantages. First, we can take direct advantage of whatever libraries and standard styles we have already created in HTML and CSS. Such HTML/CSS prototypes are perfectly adequate—possibly even better than Photoshop mock-ups—for showing to management. Second, and perhaps more important, the prototype/mock-up becomes the starting point for a seamless process moving toward actual implementation. We don’t need separate cloud-based systems for storing and sharing these prototypes; they can be stored and shared like any HTML/CSS app. This is true agility; the prototype evolves naturally into the shipping product, with no chasms to jump over. Changes to the “style guide” are immediately reflected in both prototypes and implementation.
Of course this will require designers to learn HTML and CSS. They’ve already learned Photoshop, or Figma, or what have you. They can certainly learn another environment. But there’s another problem: in today’s world, HTML is not flat—it comes in the form of templates, with mixed-in logic, such as for loops, or conditions. Designers cannot write such template-like HTML, since they aren’t programmers, and they don’t know the structure of the data which will be populating the templates, and they don’t have harnesses which can drive the template with that data.
The answer is to have designers back off from actually creating screens at all. Instead, designers should position themselves as consultants. Instead of design being a waterfall-like preliminary to development, it becomes a consultative, parallel aspect of development. Designers provide initial input on the flow, such as “there could be five screens, to do A, B, C, D, and E.”. It goes without saying that the visual elements on these screens—fonts, colors, spacing—would be defined in an HTML/CSS-based style guide which already exists. So they don’t really have to specify these things at all. They’re already specified. The designers point out deviations from the style guide. They suggest visual optimizations and simplification. Thus they provide feedback on the prototype/mock-up implementation of the screens created by the developers, in iterative, agile fashion, helping evolve them seamlessly from prototype to production implementation.
In our agile, multi-disciplinary world, why are we still treating design as an island?