Design

What is design?

There are many areas of traditional design work, I think we mostly associate with graphic arts, web or industrial design. I want to reclaim design and say that anyone can be a designer.

We talked about this idea of domain capture. That your goal in creating or solving problems is that more of the domain, meaning the possible options, is captured.

With design, we are trying to take in many aspects of the domain in at once and produce something.

Graphic design has to think about how it will affect the viewer, how it communicates a message, how it all works together.

An industrial designer probably needs to think about how materials go together, how could to be manufactured and so on.

In style, we discussed micro decisions made to reach your goal, well, I think that design is the macro level of style.

Often in our craft we are working at a certain level. You have created your own style, and you are creating. As you work on bigger projects, the domain and scale also grows.

You go from cooking, to trying to open a restaurant. Writing software to building an engineering team. From art to an exhibition.

To achieve this there is more of the domain that needs to be captured. We are working at a higher level, that is design.

All those micro decisions now become macro decisions. Our goal is to understand how things contribute to a goal.

If you go to an Apple Store and buy something. The entire experience from start to finish has been thought of and designed. Even the packaging and how you unwrap a product has had extreme care put into it.

Because they see that as part of the domain of building a great product. Not even the box the item comes in is separate from that experience.

Design is problem-solving with domain capture.

Where you work to understand what the real problem is, what the real tradeoffs are and you make something. This is a huge topic that could be a book on its own, but wants to highlight things I think are a good starting point to get into design and design thinking.

It is easy to spot bad design because it is everywhere

Even something as simple as a door can fail in design or capturing an important part of the domain, a human.

How many doors have you had trouble with because they were confusing? Do I push/pull? Is it sliding? The person that "designed" that failed at their job. Maybe they made sure the door would function in someway, but they failed in making it usable.

Don Norman in The Design of Everyday Things says

Two of the most important characteristics of good design are discoverability and understanding.

And goes on to say that it should be clear "what actions are possible and where and how to perform them"

A door that had a handle on the push side presents seemingly two possible actions even though only one is possible.

If you are designing things for humans, then part of your domain is human psychology.

So why does this happen?

Built not designed

This happens because most things are built, not designed. This goes back to our intermediate stage. Most solutions come out of just trying to get the job done using known tools.

People hobble together things to just get something to work. They lack the skill, time or money to create a good solution.

This is the Rube Goldberg method of building things.

To stay with the door theme, there is a set of doors in a very new modern shopping center near me that are the absolute worst.

There are two sets of doors and the problems are double.

They are automated doors that have an aggressive and shitty mechanism, so you just try and push on them the door fights you until it realizes you are not going to give up and then the "automatic" part kicks, and the door opens, painfully slowly.

Instead of just overhead motion detectors, they have added infrared sensors for some reason, but they really suck.

They are nowhere near the doors. So you have to walk out of your way to hit the sensors. Since they are not push and infrared, no touch, post covid style, they require you to wave your hand past them.

But the sensor is the size of a stamp, and you have to do it very slowly; otherwise it doesn't work. I hate these doors. They completely break your stride and there are two sets, so you have to either deal with the push, freezing or do the double hand wave things against to overly sensitive sensors that barely work. Either way, you are spending time just trying to get the fuck out of the building.

This is a good example of built not design. It is difficult to imagine that anyone person looked at the whole system at one time. This was probably a bunch of independent people making poor decisions.

I found cheap doors here, oh well, we have to by law have automatic doors, ok slap these sensors on, but the overall layout had already been designed, so there is no good spot to place the sensors, oh well just install on the wall 10 feet away from the doors.

This is why design by committee usually fails. Hallmarks of built not designed

• No overarching design that captures all the aspects of the problem. (Multiple people looking at only a small portion of the problem)
• Trying to Rube Goldberg a solution together with a bunch of things
• Lack of skill to capture the true domain of the problem

With processes, this can drift into the Kafkaesque.

You need a bank account to rent an apartment, but you need an address to get a bank account.

Enough with bad design, how do we design good?

Capturing the right problem

Sometimes the problem is to discover what the problem is - Gordon Glegg

Another way of saying this is that most products/services/regulations etc. fail to capture or understand the appropriate problem.

MP3 Player

Let's use the original iPod as a case study. There were plenty of MP3 players on the market before the iPod. There were even ones with hard drives that stored a ton of songs.

Here is how they seemed to have been built by most companies. Get yourself a sound card, a hard drive, some off the shelf display, and boom you got yourself an MP3 player. Built not designed, more like cobbled together.

Ok, , but people need to interact with it in a multitude of ways. Power it on/off, navigate the now 10000 songs they have on the device, all the various play controls, also you have all the device settings. What do you do?

If you are boring, you do what is easy. Easy is what is low effort, you grab what is at hand and what is known. Well, the "designers" knew buttons, and they are easy, so let's just add more buttons. This constantly happens. Just add more buttons. This is a common thing, looking at your terrible microwave.

Ugh, look at these things.

Apple

What did Apple do differently? They realized that the real problem of creating a useable MP3 player is not building the basic hardware, is how do you realistically interact with 10000 songs? How do you find the Artist/Album/Song that you want?

This is the real problem. Having a huge hard drive of songs is useless if you can't actually play the songs you want. Clicking a button a thousand times is not fun.

There wasn't anything off the shelf that could do this.

So Apple invents the scroll wheel. The whole thing has basically three interface points. A screen, a scroll wheel, and a button (ok first one had buttons around the wheel, but they corrected that quickly).

The iPod's interface required just a second to get a fundamental grasp of how to use it and once you did, you were done. Every new feature fit into an already existing cognitive framework.

Once created it paid dividends for multiple generations of the device. The technology, thought, and work behind this was incredible and difficult, but it created a simple (not to be confused with easy) solution. The scroll wheel on the iPod was looking at the larger UX/UI problem and created a simple solution to it.

I can't stress the importance of this step. You will hear people just automatically jump to a solution or a tool. We need an SDK or an app. Why? Maybe it is true, but what are you trying to do? What major problem are you trying to solve?

Simplify

After you have figured out the right problem to solve, the next barrier is to find a simple not easy solution to the problem.

Simple isn't easy.

Simplicity is the ultimate sophistication - someone

Anybody can make the simple complicated. Creativity is making the complicated simple - Charles Mingus

Our goal is to solve problems.

I am cribbing a bunch from Rich Hickey's "Simple Made Easy" talk, but to define our terms better, an easy solution is one where it is easy for you to implement. You use what is at hand, what is easy for you to use.

The Rube Goldberg machine is the easy one.

You grab whatever is at hand and just start, linking things until you have something that kind of of works.

The easy solution has no coherent thread. It is hard to maintain, to extend and difficult to explain to someone else. Because it is made up of a ton of small parts, there is no overarching pattern to the system.

It is a mess of separate solutions being used to solve a bigger one.

The Rube Goldberg machine doesn't have a mental model. So there are no high-level concepts to grasp. Without these, every part is memorization and any changes require digging into specifics.

Easy solutions are about the effort it takes to make them.

Simple solutions are about capturing the problem in the right way so you can provide a simple answer. Instead of 20 buttons, one wheel. Simple solutions compress the problem space.

Simple solutions tend to capture more of their domain and do it with less.

If you can't make it simple you haven't understood the problem.

When a solution that matches the problem and does that using the most efficient way as possible, we call that elegant.

Design Process

The Co-Evolution Model

There is a design model called the Co-Evolution that is described in the book "The Design of Design" by Fred Brooks.

The basic idea is that design is a process that repeats itself. You design something and in doing so, you learn about the problem and the solution, which can improve your design, rinse and repeat. That is why prototyping is so helpful.

The prototype can serve as act in two parts. One to figure out the solution, but also to better understand the problem, which can then lead to better solutions.

I think SpaceX's raptor engines illustrate this idea well.

I don't know anything about rocket engines, but to me, this seems like a perfect example. In the beginning, there are cables, tubes, all sorts of things running around. With time, the problem is better understood, and things that seemed to be separate could be unified into one thing.

I am not sure, but it appears that the later ones are easier to understand and reason about. The early ones have so many parts that it is it seems harder to keep the whole thing in your mind.

Which is another reason to try and make simple solutions because people have to work on these things and if you can't build a mental model of a thing then you can't really work well with it.

At each step in the design process we are trying to reduce, simplify and combine.

Design Principles/Goals

It helps to have a design philosophy. When designing things, there are many decisions to make, micro and macro. Having an overarching design philosophy helps to fall back on when things aren't clear, or you are starting out.

Guiding principles that help you make decisions. This is where there are design philosophies like Bauhaus.

Apple has style for sure, but also a design philosophy on minimalism, sometimes annoyingly like removing ports. Regardless, across every product you can see a design principle present.

In software, a common design principle is orthogonality or often talked about a separation of concerns. Or as Frederick P. Brooks explains it, "Do not link what is independent".

In software, one of the beasts you are fighting is complexity and so it is a good design goal to try to keep things as separate as possible. If everything is connected, it is hard to reason about and when something fails, then the whole thing fails.

What are your design goals?

As you start designing, you should be reevaluating your goals.

• What do you need to achieve for this to be a success?
• What are the secondary goals that you hope to achieve?
• What parts of the domain are you trying to capture?
• Are you solving the right problem, at the right level?

For a software project, it maybe this needs to do X and scale to N requests per second.

A secondary goal might be that it has to cost < then Y.

Then domain capture would be around how are you going to maintain it, how do you deploy, test, and debug when it is live?

Again, we are going for mastery, it is not enough to just stand up a solution.

For things that interact with people, many of your design goals may be around ease of use. Even in programming, a design goal maybe making a system that is easy for some new to pickup.

We build things for others, and they are a part of the domain we are trying to capture.

Design Strategies

Solving problems by finding alternatives

Often times, people get locked into a path and think they need to solve things in a certain way. The problem is not wrong, but there are often simpler alternatives.

Like many transportation options around the world, things have digitized but often still requires some stupid app.

The London underground just uses RFID and not an app. So I could just use Apple Pay and get on the "tube". No app, no figuring things out. It is wonderful.

This requires a mindset shift - One to focus on the problem our outcome and to not settle for the first solution.

If you feel like your design still calls for a lot, look to see if there is an alternate way of doing something but getting the same result.

Making small bets

When haven't fulled figured out the problem, make small bets while iterating.

Try to avoid one way door decisions or things that are difficult to unwind, or another walk away from.

Rule of three

A slight version of this is the rule of three. If you are trying to design something, wait until you see three different examples before making big design decisions.

This could be three types of users, or if you are working with different devices, there different types of devices. The goal is to try and see the possible variations before designing.

Avoiding pre-optimization

Another thing that often happens, especially in software, is pre anticipating requirements. Oh, in the future I am sure a customer will need this, or the product team will ask for this. Or this needs to scale to x. Make sure those assumptions are correct because in my experience they are rarely and they have real consequences.

The reason we use the rule of three and make small bets is because it is very difficult to predict the future will actually turn out to need.

There are several products that ship with features that are never used. The original Nintendo NES console had an expansion port on the bottom that was never used. Maybe they used it internally, who knows, but if not, then hours were spent designing and building this thing. Money was spent on each console made for something that served no function.

Take away something.

Constraints not only shrink the search space, they challenge, the designer, often thereby stimulating a completely fresh creation - Frederick P. Brooks, JR.

This is something I try to do all the time, it is a challenge to try and design a solution by taking away your go-to tools.

This is a good exercise to prevent just adding buttons like on the cheap MP3 players. Take away something or limit yourself to a few things and see where that forces you to go. Can you combine things? Is there a better solution or a larger problem to be found? Oh, my problem is a UI problem, if I had a better UI like a scroll wheel, then this eliminates the need for all these other things.

I think this is a good challenge to push yourself in the design process.