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.

our truly quirky dimensions are never really grasped by these recommendation algorithms. They have all the dullness of a Demographics 101 curriculum; they sketch our personalities with the crudity of crime-scene chalk-outlines. They’re not wrong about us; but they’re woefully incomplete.

The metaphor suggests precisely what to do: If you want to have wilder, curiouser thoughts, you have to avoid the industrial monocropping of big-tech feeds. You want an intellectual forest, overgrown with mushrooms and towering weeds and a massive dead log where a family of raccoons has taken up residence.

For me, it’s meant slowly — over the last few years — building up a big, rangy collection of RSS feeds, that let me check up on hundreds of electic blogs and publications and people. (I use Feedly.) I’ve also started using Fraidycat, a niftily quixotic feed-reader that lets you sort sources into buckets by “how often should I check this source”, which is a cool heuristic; some people/sites you want to check every day, and others, twice a year.

Other times I spend an hour or two simply prospecting — I pick a subject almost at random, then check to see if there’s a hobbyist or interest-group discussion-board devoted to it. (There usually is, running on free warez like phpBB). Then I’ll just trawl through the forum, to find out what does this community care about?

Games felt like they were about sparkles and tension. Great app UX is about minimalism and simplicity. Fortunately, I found Raph Koster, the author of A Theory of Fun. Raph is known as a “Game Grammarian” and deeply deconstructs how games are made.

Another more modern example is this landing page for PayPal. Notice how the page clearly invites you to choose. Are you a “Personal” user or a “Business” user? As you mouse over each section, the story unfolds, expanding your choices, offering you things you can easily understand and identify with. Each branch has a clear call to action. This is a beautiful story telling sequence that pulls you in and gets you to become an active part of the on-boarding process.

There are clearly 3 distinct versions of jumping going on here: Initial jump. Simple button pressLong jump. Long button pressLanding jump. Timed jump What’s so interesting here is that there is only one ‘thing’ you’re learning: jumping. But by stressing subtle aspects of how to jump, the game builds up variations of it. A basic jump gets you over things, a long jump can “open” and landing a jump can “attack”. A boring app designer like me would assume you’d need 3 different verbs/buttons for this but Super Mario does this with a single “Jump” action.

APPSEach feature is in isolation, how it is done usually has little relation to other features (other that using a style guide).GAMESBuild a game through a single, mechanic that grows in expressive power by adding modifiers like time, special keys, or timing.

APPSJust throw in a bunch of features into a pot.GAMESUnderstand everything is a journey. Work hard to make everything a closely connected arc of events that help the user create a narrative that matches the overall story.

APPSAssume users are at a constant skill level.GAMESUse hints constantly and patiently to move users to the next level.

APPSTend to offer users a large toolbox and let them figure out how to get started.GAMESHave a clear understanding of the journey and say “Start here first”.

The Mac took a very hardware driven concept, turning on your computer, and turned it into theater. Yes it had the boot sound, but it then showed a promise, a compromise of the final desktop and as it booted, ‘inflated’ that promise with the final working model. Why people loved the Mac is often misunderstood. I’d claim that it’s this dedication to taking people on a carefully crafted story, one which allowed users to craft a compatible narrative, that is at the heart of this devotion.

To win the level you must first cross the street. To cross the street requires that you move the frog. To move the frog requires that you understand joystick timing. Each of these sub levels have their own feedback considerations: Street: the cars movementFrog: How it moves, how far it jumps each timeJoystick: Direction and speed of movement (it’s quite slow actually) Games understand that each of these levels has their own set of feedback, motivation and learning that must take place. This level of deconstruction, in a 30 year old game no less, blew my mind. Games were complex! They really paid attention to detail. There was a lot here to understand.

The computer example here is desktop menus. “Selecting a menu item” is actually a fractal cascade of skills where you first start horizontally browsing the menu bar, with a click, you shift into a vertical mode but keep the same basic highlight approach. For hierarchical menus, you need to understand the graphic hint that there is something deeper and then navigate over to reveal and then select that menu. Anyone who has taught beginning computer users the menu system knows how hard it is to master hierarchical menus. It’s takes practice to find, reveal and track over to that menu. There is a fractal cascade of skills required.

Raph has a great quote in his book for this: “Fun is just another word for learning”. In order to have fun, you must learn. I find this inspiring as app design wants your users to learn but we’ve rarely appreciated this could be fun. Games understand that in order to learn you must start thinking in layers. Begin with a basic skill and slowly add more, getting better one layer at a time.