Poor design meets one need while creating a dozen others. Good design resolves problems without negatively affecting anything else in its ecosystem. We call this lens of thinking "systems thinking." It tends to separate the genuinely great designers from the pretty-great ones. The designers who do tremendous work know that what they're creating does not exist within a bubble. They understand that the context of what they're making plays a vital role in how the team should build it. They know how what they create affects everything it touches, particularly the people. The design is intentional. Trade-offs are known, weighted, and decided on. Not only in the immediate problem space but in the surrounding spaces too.

To find jobs more quickly, students tend to showcase the types of work most in demand in our industry, making website and app redesigns the overwhelming majority of case studies being published.

The myopic focus on shorter time-to-job metrics requires schools to standardize their design curricula — a trend which is reflected in the structure of case studies being produced.

The UX bootcamp also benefits from its students’ projects being published on Medium: case studies become content marketing that helps attract new students — and therefore revenue.

How can you differentiate yourself when applying to a position, if case studies from other candidates look exactly the same at first glance?

formulas create the illusion that real projects will always follow those same predetermined steps. In reality, working with both in-house and agency teams is too chaotic to apply a one-size-fits-all methodology

Research budgets are not always available; user journeys are not always necessary.

Many case studies start with an unexplained “user need” that one infers is the student’s personal need (e.g. "an easier way to share music on Spotify"). User research is then utilized in an attempt to prove that other people experience the same problem.

Because students are used to ticking boxes on a standard design process template provided by their school, they forget to explain why they are utilizing a particular method. If everyone’s process is somewhat the same, what is your unique angle to the way you work?

Insights gathered from one step are rarely applied to the next one. As a result, most case studies feel complete, but few feel smart.

Many case studies describe the project process in great detail, only to conclude with a solution which is predictable, unpolished, and/or lacking insight.

There are only so many audiences a single case study can speak to. If the student’s main objective in creating a case study is to get a foot in the industry, it might be a good idea for them to prioritize recruiters and hiring managers when thinking about their public-facing output. Ultimately, recruiters are the ones who screen candidates and hiring managers are the ones who make the final decision.

Because their time is limited, most hiring managers do not go through a designer’s entire portfolio, but instead review a couple of case studies

Since they must review a high volume of case studies as part of the recruiting process, hiring managers rarely read thoroughly, but instead quickly scan students’ work in search of talent

First [I do] just a quick scan. If the work looks interesting then I proceed to a more thorough analysis. This can range from 30 seconds to 15 or 20 minutes, it all depends on the quality and quantity of the work. Weak portfolios get discarded in seconds. Really good portfolios are analyzed in-depth and I usually end up on the candidate’s website or Twitter account. — Head of Design, 13 years of experience

Another common concern raised by the upper-level managers we spoke with was the extreme focus on the part of students on the design process, at the expense of the quality of the output. They reported that this was especially the case with UX and product-focused portfolios.

I jump to the final designs, I want to see the outcome of the case study. Only then, if the final designs are solid I go back and try to understand the designer’s process. You see a lot of people building really deep use-cases, but the execution fails and right now I need designers who can think and deliver, not one or another. — VP of Product Design, 17 years of experience

Your case study structure should reflect the areas that most interest you as well as the ones that will help you reach your personal goals. What type of company do you want to work with, and what kind of story will make the design leadership of that organization excited about the possibility of working with you?

If UI design is one of your strengths, showing personas that are shallow or unresearched can hurt more than they can help.

If you are writing about a real project for a real client, it’s important to explain the constraints and limitations around which you were working. If there were no constraints involved —as in the case of a project completed as part of a UX course— hiring managers will expect the designs to be as as innovative as possible, and will be frustrated if they are not.

Focus on insights rather than process

Reading an insightful case study is much more exciting than reading one that is complete but uninspired.

Would someone feel compelled to retweet a random sentence from your case study?

how you brought those insights to each subsequent step of the process.

The case study should tell a story about how you think and how you design — it's never about the project itself. Ideally, your case study should reflect your personality so strongly that it would feel out of place in any other designer’s portfolio.

What excited you the most about working on this project when you first received the brief?

A case study should focus less on the project it portrays and more on the skills and personality of its designer.

it should provide a platform for you to talk about the things you believe as a designer: your passion (reflected in how much time and attention you invested in the project), your thinking (demonstrated by how you connect the dots throughout your process), and your insights as you learn new things and evolve in your career.

In complexity science, ‘emergence’ describes the way that interactions between individual components in a complex system can give rise to new behavior, patterns, or qualities. For example, the quality of ‘wetness’ cannot be found in a single water molecule, but instead arises from the interaction of many water molecules together. In living systems, emergence is at the core of adaptive evolution.

Design for emergence prioritizes open-ended combinatorial possibilities such that the design object can be composed and adapted to a wide variety of contextual and idiosyncratic niches by its end-user. LEGO offers an example — a simple set of blocks with a shared protocol for connecting to one another from which a nearly infinite array of forms can emerge. Yet as we will see, design for emergence can generate value well beyond children’s toys.

In contrast to high modern design, user-centered design takes a more modest position; the designer does not inherently know everything, and therefore she must meticulously study the needs and behaviors of users in order to produce a good design. User-centered design remains the dominant design paradigm today, employed by environmental designers, tech companies, and design agencies around the world.

In this paradigm, design is about gaining knowledge from the user, identifying desirable outcomes, and controlling as much of the process as possible to achieve those outcomes. ‘Design’ remains synonymous with maximizing control.

But consider even the ‘desire path’ example pictured above. The modal user may be well supported by paving the desire path indicated by their behavior, but what good is a paved path leading to stairs for a wheelchair user? In practice, user-centered design tends to privilege the modal user at the expense of the long-tail user whose needs may be just as great.

User-centered design has a better track record than high modern design, but it still exerts a homogenizing effect. The needs of the modal user are accommodated and scaled through software or industrial manufacturing, while power users and those with edge cases can do nothing but actively petition the designer for attention. In most cases, diverse users with a wide variety of niche use cases are forced to conform to the behavior of the modal user.

In design for emergence, the designer assumes that the end-user holds relevant knowledge and gives them extensive control over the design. Rather than designing the end result, we design the user’s experience of designing their own end result. In this way we can think of design for emergence as a form of ‘meta-design.’

In other words, to address the long-tail problem, the tool must be flexible enough that it can be adapted to unexpected and idiosyncratic problem spaces—especially those unanticipated by the tool’s designer.

In contrast to user-centered design, design for emergence invites the user into the design process not only as a subject of study, but as a collaborator with agency and control.

What all these tools have in common is support for open-ended adaptation to highly contextual problems without the need for technical knowledge. Rather than building a static, purpose-built solution to a single common problem with lots of users (and lots of competitors), they’ve won robust user bases by supporting a broad swath of long-tail user needs.

Design for emergence is composable. It provides a limited ‘alphabet’ and a generative grammar that’s easy to learn and employ, yet can be extended to create powerful, complex applications. As Seymour Papert once remarked, “English is a language for children,” but this fact, “does not preclude its being also a language for poets, scientists, and philosophers.”

It creates more generic-looking interfaces that may perform well in numbers but fall short of appealing to our senses.

It’s easy to make data-driven design decisions, but relying on data alone ignores that some goals are difficult to measure. Data is very useful for incremental, tactical changes, but only if it’s checked and balanced by our instincts and common sense.

It became clear to the team in that moment that we cared about more than just clicks. We had other goals for this design: It needed to set expectations about what happens next, it needed to communicate quality, and we wanted it to build familiarity and trust in our brand.We could have easily measured how many customers clicked one button versus another, and used that data to pick an optimal button. But that approach would have ignored the big picture and other important goals.

Not everything that can be counted counts. Not everything that counts can be counted.Data is good at measuring things that are easy to measure. Some goals are less tangible, but that doesn’t make them less important.While you’re chasing a 2% increase in conversion rate you may be suffering a 10% decrease in brand trustworthiness. You’ve optimized for something that’s objectively measured, at the cost of goals that aren’t so easily codified.

Design instinct is a lot more than innate creative ability and cultural guesswork. It’s your wealth of experience. It’s familiarity with industry standards and best practices.

Overreliance on data to drive design decisions can be just as harmful as ignoring it. Data only tells one kind of story. But your project goals are often more complex than that. Goals can’t always be objectively measured.