What UX design can learn from industrial design.
About the form finding process in interface design.
What drives me crazy as a designer is how hard it is to communicate all the nitty-gritty features and fine levels that a web interface can have. There are button states, animations, different modes of pages or the responsive and fluid behavior of the layout.
As a tool, Photoshop has already become obsolete. Static layouts can not explain what is needed when briefing to the production team. And describing all these little visual details requires a bunch of blueprints and extra work.
Since we need to look at a design in a realistic environment there is no better way than prototyping and modelling it. The process can be compared to modelling a physical product, but in some cases industrial design is still more efficient. Especially when it comes to decision-making and to figure out what to pass over from the design to the production phase.
Every economical design consideration starts with market and business insights and when it comes to product design: the relationship a designer creates to the material of choice. So let’s start with what comes before the blueprint in industrial design: the form finding.
Form finding with the intended material
Many elements influence the design process: the user’s needs, the market and competitors, the approach of the people producing it and last but not least the material it is shaped with.
Somehow there has been a lack of understanding of what material the web is made of. Since many print designers reinvented themselves as web designers the knowledge of that material is still not very common among interface designers. A deeper understanding was created by articles from Kevin Goldman or Paul Robert Lloyd.
Many of the iconic industrial designers worked close to the workshop. Working with the material. Prototyping, testing and shaping their designs with the material in focus.
And even if industrial designers just delivered a design model not made with the intended material, they would still fill their desk with examples of materials to experience the material’s properties and the methods that could be used to get it in shape.
This idea can also be brought to web design. Many front-end developers will agree: most of the times there are different ways of constructing a layout. However one way may be more appropriate and behave better in terms of responsiveness, performance and quality of code.
In an interview for the movie Objectified Apple designer Jonathan Ive describes the work on the macbook air as follow:
“The design of [the macbook air] … wasn’t the design of a physical thing.
It was figuring out process.”
By process I assume he meant the production process and how to get to a certain construction. This example shows how part of the process of finding the right shape lays in the production process itself. The way to get there is by playing with the material. And then shape the design out of it. From this perspective an understanding of the material is essential for designing on a professional level.
Models in industrial design
Designers use different kind of models to show and test drafts. Depending on the stage of the draft it makes sense to use a model that emphasizes one or another aspect of the design. In some cases that aspect might be in the construction, another aspect can be in the look&feel. In industrial design, while there may be many more models, it seems to be a standard practice to focus on these three:
(1) The functional model
A functional model demonstrates part of the functionality of a design. It is used to check feasibility, define functionalities and usability.
(2) The design model
Just look — don’t touch! A design model just displays the design or shape. Sometimes it will look as if it was usable, but would actually break if used. Design models, even if not functional, give an understanding of the dimensions, proportions and appearance of the draft. Sometimes different materials are used to simulate those that will be used in mass production.
(3) The prototype
A prototype combines it all. It looks nice and works (in many ways) like the final product will. Sometimes the prototype just differs from the actual product by not being produced in a large scale with mass production tools. (You might think of a prototype more flexible, but let’s keep it like this for the scope of this article.)
Interface design uses similar strategies. Functional models are comparable to wireframes or technology driven prototypes of GUIs.
Design models can be compared with static screen designs. Mockups or style tiles would also fit in this category. They work very well visually but are never really functional. These drafts could even get clickable with apps like Pop, where screen designs or paper sketches use links to give the feeling of clickable pages. When using nice layouts as images these prototypes look nice, but still the feeling is not realistic. So in the end it does a good and fast job in pretending — which is fine for that purpose.
If you’ve ever seen industrial design prototype, let’s say for a wooden chair, you may know that all of the modeling attempts are not even close to the final prototype. They are still far away from the actual chair. The prototype as crafted in the intended material, can be used and tested as if produced in a large scale.
Sometimes the model can also be the start for building the tools for mass production. In this case the model is used to make the moulding by casting a negativ of it.
Here is an example of a project I did in 2004. A model for a seat cushion becomes a mass production mold:
For some reason this approach is not used for prototypes in the UI design process. And I ask myself why, because it seems to me the best form of briefing a layout as the first step into development.
A prototype, ready for production
What would that prototype for UI design be?
In my mind, the most interesting idea is that of reusable code. It saves time for production and design. It can push the quality and get rid of parts of the briefing to production and the design review.
Going back to the industrial design analogy, using reusable code means the prototype should use the intended material. And let’s be honest: this shouldn’t be to hard in software — at least for the HTML/CSS part.
I can see many people screaming “STOP, there are tools who already attempt to do it”, such as Macaw or Adobe Edge Reflow. But in the end they don’t, because they have limits. They rather don’t support different screen sizes, limit the creativity and possibilities a lot or export crappy code that no one wants to use in a real environment.
Let’s define the hard requirements of such a UI-prototype:
- Needs to work in one browser at least (to display the intended layout and behavior)
- Since it is the first step into production, it has to be reusable code (human readable, maintainable ,… yeah I know … already a bunch of requirements on it’s own)
- Should define as many dimensions of UI design as possible (responsive layout, animations, behavior, click flows …)
What will the front-end developers do then?
The relationship between UI designers and developers in web design can be compared to that of designers and model makers in industrial design.
So when this functional prototype I suggest hits the development team, there will still be tons of stuff for the developers to do. Designers are not experts in front-end code, so developers will need to refurbish parts of the code. Some other stuff that remains open in a prototype is:
- Connections to API / backend
- Fallback and browser support
- Optimization of the assets for loading performance
- In most projects the designer will not build all elements, but a representative mass. The front-end developer can derive other elements from this patterns. This is a quality of the coder of course. My experience is it does not work with those developers who are missing a general understanding of design.
- There can be work for the developer beforehand, since it makes sense that the designer uses framework or boilerplate that the development wants to build upon.
- Well, I am a designer… So there might be more I not noticed :-)
My personal experience with this approach is that the process itself does not change much. There is still a design briefing, followed by production/development and probably a design review before the shipping of the deliverable.
The difference is in the quality and the format of the briefing that goes from design to production. While there might still be a need for an additional blueprint for IA and other things that the prototype cannot capture, with the first steps in code designers can define many more details going beyond explanations in charts and briefings.
