No Computation Without Representation
Finding affordance in high-performance digital design
Digital Product design studios sort of remind me of Raymond Loewy, The Father of Streamlining and The Father of Industrial Design. He designed some cool things. From trains, cars, logos, and pencil sharpeners. The bullet-nosed design looked futuristic, but was purely expressive. It had nothing to do with aerodynamics or performance of the pencil sharpener...
I’m not trying to hate on the dude. It worked back then. I think it still works for some of the current industrial designs too, but this kind of abstraction only works when properly represented.
So what is the relationship between digital product and digital design?
“A Digital Product is a software enabled product or service that offers some form of utility to a human being. “— Jules Ehrhardt
The user experience(UX) digital devices that allow users to accomplish utilitarian tasks, requires minimal device performance in terms of computation to complete various tasks. Digital products like those built by Facebook, Uber, and Chase rely on existing performance levels of computation, and focus on manipulating code to produce reliable, and functional digitized interactions.
So what constitutes high performing computation?
Looking at the automotive industry, Formula 1 race cars are the highest performing motor vehicle in the world. By this fact it also defines a section of socio-economic identity that participates in producing this playground. When replacing some of the words from Ehrhardt’s above definition of ‘A Digital product’ we can see that an Automobile is a vehicle that offers transportation utility to a human being.
Multiple systems of roads and production methods have been created to better utilize this vehicle, enabling users to get from point A to point B with minimal performance from the vehicle itself.
So what is the meaning of Formula 1’s high performance as a automobile?
The meaning is not simply who can get from point A to point B the quickest. Higher performance show less relevance to the intended utility of transportation because an ecosystem was created with different framing. An ecosystem focused on automobiles that is sustainable through different means of utility, economic, business, and political values.
The automotive racing industry maintains procedural rhetoric of creating higher performance by cultivating affordance. Finding that which is invariant will help clarify the ambiguity of transportation’s value.
This playground produces high performance environment depending not only on the driver, but the constructors including engine mechanics, aerodynamics, sponsorship, and tyre technology. The people who produce performance for these different sections are defined as a team.
So what is the equivalent of F1 in computation?
All software runs code, but videogames tend to run more code, and also to do more with code. Recalling Crawford’s term, videogames tend to offer more process intensity than other computational media. Videogames tend to demand a significant share of a computer’s central processing unit (CPU) resources while running; they are more procedural than other computational artifacts.
Process-intensive programs like videogames are not guaranteed to mount more interesting or sophisticated procedural rhetorics, but they are predisposed to do so.
This explanation directly relates to the aesthetic value that stems from process intensity in current gamer culture.
For a professional gamer, the design of a gaming setup is dependent primarily on performance. The seat that give longevity and comfort, video card and DDR enhancements to the gaming system and; added components to sustain a low temperature level to avoid over heating all contribute to the gamer culture’s desire for highly performant computers.
By comparison, a lawyer whose digital use revolves around Microsoft Office, and Gmail does not require the highest computational performance. By seeing the two generations of high performance mechanisms, it is easier to understand why the concept of gamification in a digital service product is somewhat laughable. Because,
“maybe life is like a bad game.” —Ian Bogost
Hoping to give some context on what high performing computation might look like, let’s try to identify some computational representation. With my example of automotive industry, it is easy to see how broad the affordance can get when you are trying to define ‘Digital product’ without a proper invariant in utility. I have mad respect for Jules Ehrhardt for his analysis on the current state of digital industry. As he does a marvelous job explaining the business of digital.
However I must disagree when he simplifies a computational device as “a software enabled product or service” He broadens his definition by saying,
‘Digital product’ or ‘product’ work is the delivery of the digital touchpoints of a product or service.
To be honest, this statement is just as ambiguous as saying ‘Automobile’ work is the delivery of the driving touchpoints of a vehicle. What does that even mean when it comes to the performance of a digital product design?
I defined high performing computation in the first segment to compare and contrast Ehrhardt’s following statement:
Whether in-house or in a consultancy, building and running high performing design and engineering teams is extremely difficult. Really! That shit is super fucking hard. You could hand pick a team made up of the very best players from any league of any sport and still have a team that stinks compared to a cohesive, well-drilled team. On top of that, achieving a truly product oriented ‘one team’ approach with tightly integrated designers and engineers is even harder. (Any team that has engineering on different floors, buildings, states or even countries to design is building weakness into the system).
So if a consultancy can offer the above, something that even some of the world’s wealthiest companies can not pull off, then you’re going to get business even if there are internal design departments in place. Design as service is far from dead.
In a business mind set this makes perfect sense. But let me attempt to clarify a bit more affordance regarding this suggested solution. David Heinemeier Hansson(DHH) writes:
“An anecdote from John Carmack, the legendary programmer of Doom and Quake. He talked about how when he was working on a new game, he had to program not for the performance of today, but for the performance of three years in the future, when his game would be finished. If he programmed for today, it would look dated when it launched. Doom and Quake always looked amazing because of this.”
Programing is absolutely related to the computing performance, but this also relates with the utility to a user. Is it a high-end 3D game? Or do you want to manage your money on your iphone? There are so many ecosystems within the digital industry that a “high performing design and engineering team” is still too ambiguous without proper representation.
The question is, how do you choose the right ecosystem to achieve a high performing ‘one team’ approach, while properly representing the computational utility? Well, I don’t really know, but I’m determined to find out.
Which playground do you wanna choose to compete?
So capitalism is a thing. Competition is also a thing. But like Ehrhardt’s says:
let’s rise above success being purely defined by how much money was raised in round X or Y as that is money is invested to grow the company rather than an exit. Let’s broaden out to any of: attracting a significant user base or investment, a big exit, continued media attention or simply as having moved the needle or impacted our digital lives.
It’s awesome that Ehrhardt’s mentions DHH founder of 37 Signals as one of the success consulting companies based on the above statement because David Heinemeier Hansson is definitely on a higher level when it comes to Repping his Digital Products. And it’s pretty freaking badass that DHH is a Le Mans & WEC class-winning racing driver.
Which relates to my point that a person like DHH who knows how compete with a high performing team would also know how to make a product like Basecamp. In Hansson’s article “Program to where the performance puck is going to be, not where it has been” he explains…
Yes, the article does define some of the relationship between different programming languages and how they share the computer’s central processing unit (CPU) resources. And it’s beautiful.
A high performing design and engineering team with lower performance in computation
The Digital Product Studio has the strategic, product management, design, and engineering talent that is capable of taking a product through to market launch and beyond from meeting #1. — Jules Ehrhardt
So how do you form a high performing team in a world of digital service products that focus on reliability and functional interaction? Let me go back to the automotive industry.
It’s quite obvious that you don’t need a F1 team to manage a 1994 Nissan 240sx. Even though it is a sports car, the general utility in terms of transportation is for people who seek reliability and functionality to get from point A to point B a bit quicker.
However, just because the 240sx has lower performance than a F1 doesn’t mean the team who work with it has to perform lower. It simply comes down to giving a clear affordance in utility. It’s not enough to design a system that revolves around a definition of a vehicle that goes from point A to point B. What if you want to build is a team that focuses on a 240sx drifting than can perform highly as a transportation vehicle?
Even if the vehicle has lower performance, when it needs to be utilized in a different procedural rhetoric. It can create a higher performing team by cultivating affordance.
Now I’m no videogame designer (even though I would love a chance to experience the field), but I do want to achieve the highest performance as a digital designer. I believe this has less to do with A team built from generalists, and more to do with a multidisciplinary team who produce performance for different needs. A team with clear representation and respect.
I know that digital products and computational devices are a different can of warms compared to the automobile industry, and I’m sure my views of the digital industry will shift as I get more experience rather than writing something like this from amused research. But for now I would like to thank, Ian Bogost, Dan Klyn, DHH, and Jules Ehrhardt for providing me with awesome reading materials that influenced me in writing my opinion. It’s freaking awesome because Ian: Videogame Designer, Dan: Information Architect, DHH: Programmer, and Jules: A Designer. I think they are worthy of a F1 team.