You can use different tools.

You can test, or gain context, in different ways.

The criteria for release (shipping) may vary.

But it always fits the shape of this diagram.

I've always focused on getting better at each step of the cycle, regardless of what the tools or goals are.

Here are some examples of what I mean...

‍

Skills that apply to all types of design,
from UI/UX, to music, to web and graphics:

Knowing Sloppiness vs. Perfectionism: Knowing the difference between wasting your time on unimportant details, while getting the critical ones right.
Understanding Feedback: Understanding what people really mean when they give you feedback; i.e. being able to read between the lines to get to the root of the problem, and not just take their words at face value.
How to Learn Quickly: Being able to identify skills or knowledge you don't have, and understanding how to learn it quickly so you can keep moving forward.
Knowing When To Ship: Having a sense for when something is actually done; i.e. knowing when it is in a state that is (usually) not quite perfect, but meets all the concrete and subtle requirements that make it likely to succeed for your goals.
Understanding The Importance Of References: Understanding the importance of references, cultivating them, and letting them pervade both your conscious and subconscious mind with source material for creativity.
Deep Creativity: Knowing how to either turn off the analytical mind, or get into a state of deep focus, to tap into ideas from a deeper creative place and not settle for surface-level thinking.

‍

And there are many more.

But the point is that design is about something much more fundamental than any of the top-level methods you learn for a particular field of design.

When you think in terms of those fundamental concepts, the lines between different fields of design begin to blur, and eventually disappear.

The Cycle of Design*

^{*The process of bringing ideas to life.}

Here's a breakdown of how I think about each part of the above diagram.

‍Phase 1

Start with an idea.

Ideas can come from many different places.

It could be the clink of your radiator that makes you think of an interesting rhythm.

It could be an idea for an app, or information you need to display on a poster.

But whatever it is, it's a spark of energy. It's whatever drives you to begin.

That doesn't mean you can only start working if you feel inspired. You might sit down and just start writing, putting images together, playing around with notes, until something grips you.

But every project starts with an idea that exists only in your mind, which guides your creation of something in the real world.

That's where Phase 2, the real creation, begins.

Phase 2A

Build / Prototype / Iterate

This is where you go from 0 to 1. Or at least 0 to 0.1.

If it's the beginning, you get something down on paper / piano / canvas / Logic / Figma / Photoshop...

If it's an article, you write or improve your draft.

If it's an app, you start wire-framing, thinking through an actual user flow in Figma.

If it's a song, you start laying out an arrangement in Logic or Ableton, or on a guitar.

A key lesson here is that everything — at least everything truly great — evolves the moment you start experiencing a prototype. You can't list out everything that needs to be built and then build it, and expect the list to stay the same. If your paying attention, the project will ask to evolve in ways that you had not predicted at the start. Of course, you can't expand the scope endlessly, but you also need to listen to what it's asking for. That's where the magic often enters.

Phase 2B

Test / Research / Get Feedback

When you have a working version that you want to improve, you either

Test it;
Get feedback;
look at it in a different context;

so you can better understand how to improve it.

This could mean sharing an early version of a song with friends who come by the studio.

Or it could mean going through a Figma prototype with a potential user.

Or, often, the tester is you in a different environment. For example, you might take a demo of a song into the car. Or just view a prototype in a different browser the next day, imagining you are a user. You notice where it isn’t right, and you do your best to fix it.

There are some universal lessons about this:

What people say when giving you feedback often doesn't matter. You have to read deeper. In the case of music, people will often tell you something, but you can sense from their body language that they mean something else. In the case of an app, users might say they would prefer something different, but you have to try to understand the root of the problem that is causing the pain point they are verbalizing.
Every project requires collaboration. You always need multiple perspectives to complete a project well. This can mean the opinion of people who's taste you trust, or feedback from users. One asterisk to this is that in the absence of other people, you can collaborate with your future self. Meaning, if you take a break for some time —ideally a week or more — you can come back with fresh eyes, and sense if you were in work blindness. It's best to do both though: get input from others, and take a break to gain fresh eyes. There are a few Picassos out there who can just draw a masterpiece in 14 seconds. But for 99% of people, including me, that is not the case.

This phase could also mean research. If you're building something for someone else, and you don't have a lot of firsthand experience, you might start with this phase before you begin building. Research is sort of like testing before you have a product to test. You're just getting feedback and context before you start prototyping. This is not always necessary, mainly if you are building based on first hand experience, which is the best case scenario. But it's one variation that is appropriate at times.

Iteration is repeating these steps — Building and Testing — over and over again.

Building (Phase 2A) and Testing (Phase 2B) are an ongoing loop with each other. Each loop is a round of iteration.

If you are building an app, this could be two week sprints.

Or it could be very long and slow, like when writing a book.

It can also be extremely rapid. If you're making a painting, this loop could happen as fast as stepping back to take in the whole painting before continuing to work on one section. Or it could be exporting the demo to listen in your car, then immediately going back to the studio to make tweaks.

Regardless of the project, it's almost always better to shorten the length of iteration periods.

Phase 3

Release / Ship / Share it.

At a certain point, you have to kiss your project goodbye and release it. Musicians and designers often talk about this like it's sending a child into the world.

Some key lessons from this phase include:

Know the difference between being agile and premature. There is a prevailing wisdom that you can't be a perfectionist, and it's largely true. But on the other hand, you can't take a cake out of the oven while it's still goopy in the name of moving fast. That's a waste of everyone's time. You have to develop a sense of what matters and what doesn't. That means understanding what key pillars need to be done well in order to actually test your hypothesis, and what can wait.
The 1 in 10 rule. I live by a rule of thumb: Eight in ten projects will turn out less successful then you hope. One will break even, and one will do things you couldn't have imagined. This is my expectation for everything I carry through the above cycle. I hope the odds get better as I get better, but I still set my expectations by this rule.

Process

Skills that apply to all types of design,from UI/UX, to music, to web and graphics: