UI Design is the past, welcome Visual System Design
A deep analysis of the role of UI Design in modern Software Development and how it can be better.
I have delayed the release of this article because it has been re-written at least 3 times. To be honest, it’s not an easy topic to address. Initially, the reason why I decided to write this, it was because a simple question that came up to my head: Are we approaching design (and especially UI Design) in the right way? Probably there is no correct answer as there is no right way. Technology is always moving along with all their parts, that’s something I’m glad I could learn from developers, but that evolution of the things is what it worries me. Change is good because it means we are evolving. But, how much the UI Design has changed over the last years? Prototyping and the new tools now available have improved the communication of course, and it allows us to create more interactions, but at its core, is UI Design evolving at the same rhythm as the other areas of the product development process? Through this article, let’s try to find an answer to that question, and also let me share some thoughts about how Design can evolve in a right direction.
Just to keep an order and to put some borders around what this article is about, here are the goals I’m trying to accomplish through it:
- Make an analysis of the current best practices in Software Development, and identify the role of design.
- Identify if the current UI Design approach works, and if it doesn’t, find the reasons.
- Share a personal opinion about possible solutions and propose a new approach.
- Make a brief exercise about how to solve the biggest challenges of the approach, based on the currently available tools like Sketch.
Let’s get started!
The keyword of the big picture: Cycles
I’ve always been skeptical about Agile because I’ve been witnessing over the last couple of years how many companies have acquired a blind trust in the Agile techniques and processes. Now I realize that I’ve been wrong the whole time, Agile has never been the problem, it’s the high dependency on the processes the real problem. A problem that creates strict workflows where the iteration rhythm decreases. Each company struggles with their own challenges, so we can’t put all the eggs in one basket, but two of the most common concerns are always around quality and time, so it’s understandable the trust in a methodology that, in theory, promises us an efficient process.
Those who are not familiarized with Agile, the concept is really simple, and beyond the vast amount of content generated around it, it’s highly important to be aware of its core goal — to build a product by cycles:
There are a lot of benefits to this approach, but the most important one is increasing the iteration rhythm to accomplish an effective evolution of the product over time. Although overall it’s crucial to understand what this means:
“A product is never finished, there is no such thing as the final design for a product. It’s a living organism.”
In theory, everything makes sense and should work smoothly, right? But the reality can be different, there are a lot of factors, and each part has its own challenges and problems to solve in order to avoid bottlenecks. Developing, for example, has plenty of techniques and approaches to being always more efficient (like Scrum). Design on the other hand… let’s face it, folks, we can do it better.
Let’s put our attention on the Planning part of the process. This part is crucial because not only it receives the feedback and requirements from the stakeholders, but it also determinates the requirements to be prioritized, and here is where we make design. Zooming in on this part, right now, at a high level; usually, it looks like this:
Did you see the problem? It’s quite linear, and the risk to fall in bottlenecks is really high. How is it possible that in an environment where cycles are the rule, this planning and design process is highly dependent on previous stages? There are also other concerns around this like: How to know the cost of our design decisions accurately? How to improve the design process to be more in sync with Developing? Because if we compare processes, this small workflow is very different from a standard developing process, and the reason is not hard to find; Developing has a code and a workflow structure, design doesn’t. This is a real problem, especially for the UI design work.
UI design is dead
Yeah, I know it’s a very strong statement, but let me explain my reasons why I think UI design should be the past. Starting by analyzing the name: User Interface Design. I’ve started this article with a high-level review of Agile and how cycles are highly important for an effective Software Development, but this approach is only feasible if all the parts of the iterations are synchronized. So, based on that, how is it possible that we are still making design screen by screen, interface by interface? Sounds pretty outdated, right?
Let me get to my point using a visual help:
As you can see, the current approach breaks the cycle, because it creates a bottleneck where the iteration loses its purpose, it’s not fast and the factor of time increases over time as the product itself gets bigger. Of course, this combined with other common statements that need to be reviewed, such like:
- “Every software version needs to be designed and prototyped end to end” — I don’t think so. The concept of version designing and prototyping sometimes is dangerously misunderstood. Not every screen needs to be designed, and not all the products need to be prototyped because the outcome of both is communicating an implementation. Just that. Of course, communication is highly important to an effective iteration, but the communication is not effective if we don’t consider the factor of time. How to create effective communication should be one of the key questions we need to answer through prototyping, but also through Design.
- “Design dictates what to build” — Not necessary, UX design gives the guidelines to know what to build, UI is just an extension of that, giving us more details, not just about what to build, also how to build it (using Interaction design and prototyping as complements). But with that linear approach, we do not measure “how much it will cost us to build it.” This is the reason why a synchronization between design and developing is necessary for an effective cycle.
- “Once a product is designed, the style should wait to change” — This is a very common statement, but it’s kind of frustrating from a design perspective. If the development process allows for the product to change over time, why not design? I know what the answer to the current approach is, and that is the reason of the following section.
A high-level view of a System Design approach
As I mentioned before, an evolution of a product over time shouldn’t be just constrained to functional changes, that’s an old approach where design changes are seen as not priorities. But there is a reason why design changes are costly and not priorities, and the reason is that right now much of the design work is an isolated effort. Imagine a process where UI Design speaks the same language as developing? Then UI Design turns into an active part of the cycle. Maybe you’re wondering why is this important? Because the risk of not doing that is what we see every day in early-developed products and companies which struggle with their resources: Frankenstein’s monsters. A stack of functionalities without a proper design experience for their users. We hear all the time how an MVP works, giving to the users a minimal of functionality to start the cycle, and it makes sense, but the evolution from this started point until reaching a stable version shouldn’t ignore the quality of the experience, because this experience matters, a lot.
This is my proposal: What if we make design from a “Develop thinking” perspective? Not just understanding from a design level how our product is structured, but also turning our design into a versatile environment. I know it sounds confusing, but it isn’t. Let’s get started with the big picture I had shown above, how it should look now with this System Design proposal included:
As you can see, the flow has changed, but for the better, since developing and designing now speak the same language, which allows to the planning phase (or as I changed here for “Strategy”) to be more focused on translating and setting priorities according to the stakeholders needs, meanwhile developing and designing are focused on making the iterations.
Now, as everything in life, nothing is simple. Design doesn’t follow the same logic than developing, in their cores, both are quite different. Trying to transform the design work into a developing work will be a mistake. So here is my picture how the design area should work more as a cycle considering that:
The explanation is simple: Every design cycle should be composed of 3 parts with a single input: the requirements from Strategy, but then we need to consider:
- A reusable resources management
- A Scenarios Structure
- And the “Beautiful Mess”
Don’t worry; I’ll explain in detail what each part means, starting by:
The beautiful mess
Design work at the beginning is chaotic, stressful and in many ways; a mess. I’m sure if you’re a designer you know that feeling. There are a lot of techniques to make this process less chaotic; mood boards, group discussions, focus groups, etc. Everything to reduce the risk of developing something based on a mess. But from my perspective, the mess is necessary. Design at this level can’t follow the structured rules of a traditional developing process because here is where many of the new experiences ideas are born. We can’t lose the value of that.
I’m calling it a mess because it describes the process, but if we analyze it closely, this design process has more sense that it may look. It’s hard to write it down because every attempt to have control over it will only reduce the capability to innovate. However, there are some high-level guidelines we should consider:
“Thinking always from an User Experience Outcome point of view (I refuse to use the Design Thinking term, has been devaluated too much already)”
That will give us a user perspective about the vision for the output of the cycle we’re working on, but also, it will give us a final vision of how this output is contributing to the final outcome of the product. Vision is the keyword here.
“Transform the problems that Planning is trying to solve, into needs to solve”
This statement requires a deeper study and analysis, but this is my theory in few words: Almost all the companies are trying to build products to solve problems, which also has a lot of sense. But that’s not always useful for a better output here, in this “Beautiful mess” part. Why? Take a look at the products which are ruling the market now. Yeah, all of them are solving problems, but also many of other products are solving the same problems in a similar way, so why just a bunch of them are leading the market? Is it because of capitalism? Probably. But there is another simpler reason. Solving problems only gives you an immediate solution, but transforming the problems into needs, it gives you a broader perspective to not just find solutions, also to create new experiences. For example, Uber exists because supposedly there is a transportation problem, but is it a real problem? The world seems to work fine with the transportation systems before Uber, but if you transform that not so obvious problem into a need of “having a more efficient and cheap way to travel”, then you have a more accurate description of what Uber does, because you’re not just addressing a problem, you are addressing a human need for a better experience while is being transported. You can pick the same logic and apply to many of the lead products now, and it works incredibly fine.
So, to summarize, the mess is necessary, but we need to take advantage of this mess, of the value that can add to the whole cycle, which is innovation around experiences. And this innovation ingredient, it’s only an efficient output if we consider a user POV and a different approach of the needs to solve.
Reusable Resource Management
Now, here starts the synchronization with Developing. This part breaks the old approach of UI Design. The idea is to have a reusable structure of elements, where we can be able to polish it over time. Let’s think about this resources as variables. If we change something in a variable, it will affect all the places where the variables have been used. This is not just a big change in order to be more effective in Design, it’s also a step forward to speaking the same language than the modern developing approaches, where the reusability of the components are the present, and future.
The structure of this reusable resources, it should looks like this:
Where:
- Components are all the elements that composed a view or a final scenario for the users. Components are versatile, in a way that a big component can be composed of other minor components.
- Inside the component, we use elements, that’s what I’m calling “Assets,” let’s think assets as the lower type of visual elements, for example, an icon, or a piece of text. Why is it important to consider assets? Because for example if we find an opportunity to improve our icon set. Then we don’t need to wait until a redesign to make the change, we just change or replace the icon assets, then automatically, all the design structure should change.
- And finally, we have Properties. Every asset has their own properties, like for example, the property for certain text will be composed of family font, size, line-height, etc. These properties are the same properties that a developer should put into their CSS file as variables. Again, why is this necessary? Because if we change a single property, like the color for a H1 text, then in our design file, this change should affect all the H1 texts. And with that, this required change will be clearer for developing.
As you can see, the objective of this Reusable Resources Management, is versatility to make changes using a very low amount of time, being aware of their cost since we are in sync with developing.
Scenarios Structure
Now that we have defined ways to add innovation and coherent and versatile resources structure, finally we are ready to put all the elements together, building the scenarios for the users, scenarios that would be the main resource to build our prototypes. That should look like this:
Now, instead of having a bunch of Interfaces that over time their cost of maintenance goes up, we finally have a design structure, synchronized with the code structure (at least on a front-end level). And with this, we should be able to complete a cycle in a record time. Pretty useful, right?
Finding a solution to the solution
I hate exposing a problem and a theoretical solution without giving an example of how we can make it real. And that doesn’t mean to propose a brand new product that can cover all this. Sketch, for example, is the product which has been doing great changes in this direction. So let’s take that as a base and let’s add some features.
The first thing we need is a space inside Sketch where to manage our Reusable Resources in a more proper and practical way, an evolution of the Symbols they currently have:
Now, we need a way to add these resources from the scenarios, or the art boards in this case. As I said before, Sketch with their symbols already have a nice way to do it, but maybe it can be better.
And also in the other way, we need a practical method to add created components to art boards, like, for example, just dragging them.
There are a lot more things we can include, like a place specifically designed to manage the properties, something that Sketch right now doesn’t have. But essentially small improvements like these should allow us to have a more proper tool to apply this Visual System Design approach.
Conclusions
The thoughts I’ve shared here are just the top of the iceberg of something more interesting that totally worth it to continue exploring. But just based on these initial thoughts, we can conclude:
- The foundation and core values of Agile are highly important, but we shouldn’t be slaves of our processes. We’ve learned how cycles, iterations, quality and time are the key ingredients of a successful product. What we can cook using these ingredients is the interesting part.
- How we make design is not just constrained to “draw” things into an art board. There are a lot of variables to consider if we want to fit into an effective developing cycle. And there, versatility and always looking for a good experience as an outcome for the users, are the best added values that we, as designers, can contribute with.
- UI Design, as we know it, is definitely outdated. I don’t know if this proposed Visual System Design has real value as a replacement, but it’s important to continue the discussion around how to make it better.
I hope you’ve enjoyed this article. In the same way than a product, it’s not finished yet, and I hope I can have the opportunity to continue learning in order to add more information and thoughts in future articles. Your feedback is always welcome of course.
Stay tuned!
