I play a lot of games. A LOT of them. (Seriously, I created 2 video game UX explorations for fun – #1, #2, and did a whole series of JRPG soccer kits.) I think they’re excellent examples of how UX can be (or should have been) considered in complex interactive environments and differing physical and hardware constraints. Although I’ve never particularly considered a career in game development, I’m interested in the process and have a long-term goal of creating a small game. I had always assumed that would be a tabletop game, but at the end of 2022, I decided that I would tackle Unity as my creative goal for the year.
In 2022, I chose to rebuild my main website and portfolio and danielboyle.net. At the time, things at Amazon seemed incredible stable (a recent promotion, solid core business fundamentals, and a good team). I, like thousands of other Amazon employees are now staring down a suddenly the possibility of being one of thousands of employees laid off in the next week. While I wish I could claim some special bit of insight that lead me to start working on this nearly a year ago, the reality is that:
Portfolios take a long time to build. This is a major criticism from the people who want to see portfolios removed from the hiring process. They effectively discriminate against people with full-time jobs, or multiple jobs, or family responsibilities, or something that reduces their free time. It’s a fair criticism, but as a person with family responsibilities, a full-time job, and hobbies, my free time is precious. I spent months gathering artifacts, working on content or design updates a bit at a time, between other commitments, in order to avoid a single large period of crunch.
I began to dislike the content architecture of my previous site. All of my UX work was divided into two cases studies, which were overly long and awkward to read.
One of my goals for the year had been to learn a modern JS framework and modernize my front-end development skills.
As mentioned, my previously portfolio organized all of my UX work from eBay into two case studies – one for Advertising, and one for Recommendations. This made them awkward to read – important information was removed from each project in order to keep them at a reasonable length for the overall page. Because I rarely retain the more ephemeral work – post-it notes, whiteboard sketches, and the link – this lead to the perception that I was only creating the UI.
I decided to split each project into its own case study in order to find the space to better tell the story of each project. Each project leads with results and outcomes, before diving into the details that are organized in a common structure, focusing on scan-ability. As a hiring manager, the odds that I read a full case study right away are tiny – I’m looking for key words and signals to inform my decision to dive in to the details of your work. Treating myself and my managers as the customer for this content, I’m focusing on results first, with a strong hierarchy of headers and imagines to show process, iteration, and final delivery.
My previous website was a home-brewed PHP-based templating system. It worked quite well for what it was – it effectively separated the content from the presentation logic, so I was able to easily create and edit content sections. It was, however, still difficult to create an entirely new page from scratch, and the templating logic was more complex than it could have been. I wanted to explore a modern JS framework as an alternative to this, and settled on Next.JS. I had explored a few other options, but Next.JS was fast, reliable, and the getting started guide actually produced working code, unlike several frameworks I tried.
In the end, I don’t know that this will perform better or worse than my previous portfolio, nor would I even know how to measure that. There are so many factors that impact a potential job search.
At the very least I can say:
I was able to learn to use a new technology.
That technology has made it easier to develop multiple case studies.
I think those case studies are more readable and better represent my capabilities and contributions.
At Amazon, the first time UX teammates see our potential candidate pool is what’s called a “materials review.” A group of 3 people has 90 minutes to review 15 candidates, and judge if they’ll move on to a phone screen and the actual interview loop. This means you have 6 minutes to make an impression on the reviewers. If you’re a candidate, this probably seems horrifically unfair. You (hopefully) spent far more time pulling together your case studies, and you’d like the reviewers to invest a fair chunk of time when reviewing them.
That’s not going to happen.
You need to evaluate your portfolio and understand if, in a 5 minute review, a hiring manager can see the contributions, quality, and impact of your work. This review isn’t everything – it’s just there to understand if you’re worth pursuing further, or if you’re immediately going in the rejection pile.
Note: As of this writing, I haven’t significantly updated my website in years. It doesn’t follow my own advice.
Make sure I can view multiple projects at the same time. Most reviewers try to open every project in a new window or tab. Don’t use a provider or template that forces me to click through read a single case study, scroll back up to your navigation, and click through to another case study.
Lead with the results. Show me what you created, what you contributed, and what the impact was before diving deep into the process.
Share the entire process. Don’t just share your problem, the solution, and the outcome. Particularly for student, intern, and personal projects, the process is generally an idealized double-diamond (or whatever process you pick). Take advantage of that to share the different ideas you explored, how and why you chose one solution to move forward with, and how you iterated based on your discoveries.
Seriously, show me the other things you considered and why you chose your particular path forward.
Edit your case studies. You are not writing the next great novel in your UX portfolio, and if I start to get bored, I will move on.
Be clear about yourpersonal contributions.
Make sure your problem and your solutions align. I’ve seen multiple case studies where research identifies a unique and interesting problem, only to be completely ignored in the rest of the case study. Two examples spring to mind.
An intern candidate shared a personal project on social media design. They flagged endless scrolling and a lack of meaningful engagement as a problems impacting the mental health of heavy social media users. They ended up designing an endlessly-scrolling photo sharing app with quick-reaction “swipes” as the primary engagement. Based on their own problem statement, they’re repeating the same problems.
A designer created an app focusing on childhood obesity. The UI design was beautiful, and I’m sure gathered a ton of engagement on Dribbble. They did not however, consider how they would speak to children, leaning heavily on medical terminology and “adult” langauge. At no point did they show any awareness of mental health impacts or the risk of eating disorders or other physical harm that could be triggered by this app – or even show any awareness of this.
Related to the above: don’t be afraid to go deep on a single topic. I look for interesting, complicated problems like the above. I admire the ambition to tackle them even if the solutions aren’t perfect – particularly for personal projects – when considering intern and junior candidates. I’d rather see candidates go deep on these problems, instead of ignoring them because they’re hard to solve, or because they feel compelled go wide and communicate an entire product vision.
Focus on your strengths. If you’re not a strong visual designer, focus on your research, user flows, wireframes and other non-UI deliverables. While UX work isn’t only UI, it’s possible to derail an otherwise good UX case study with an absolutely awful visual design.
Make sure your content is correct. We notice when images don’t load, or when you forget to remove placeholder content, and we absolutely hold that lack of attention to detail against you. We are, generally, far more forgiving of minor typos or minor sentence awkwardness, particularly if English is your second language.
This doesn’t guarantee you a job anywhere. But maybe you’ll have better luck.
Despite working with AI-powered systems for years, I’d never really gotten hands-on with building one. I’ve been working on this Coursera IBM Applied AI course, and finally got past the “advertising for IBM” part. Enjoy this useless chatbot.
This is a fair statement: If you are a designer, be a designer. If you’re not a designer, stop telling designers to be something else. This is also an unfair oversimplification.
What is design? In short, it’s synthesis. Whether you’re producing design systems, wireframes, storyboards, or high-fidelity mockups, your value as a designer lies in the ability to take in a dozen disparate, conflicting, ambiguous inputs and create something cohesive, whether you’re design web-based tools or a plate. You can only be good at synthesis if you are able to have other perspectives – not just that of your user, but of services, technology and business as well. To that end, learn about how to understand your users – finding their needs, how they learn, and how to teach them; but also explore web frameworks, business process, and customer service processes (or whatever needs you have).
2. Embrace design.
Your goal is to shape whatever it is that your customer will use. Use your entire design toolset to generate artifacts that shape this process – and design every single one. Every text file. Every wireframe. Every research report. Every mockup. At the end of the day, you’re not just shaping your end user’s experience – you’re shaping the experience of the product manager, who is trying to digest your user journey to understand if we’re doing the right thing (or not).
3. Designers are not researchers or strategists.
Part of embracing design is caring about craft and the end product. I don’t care how many sticky notes you use on a daily basis – our job is to craft a product or experience. If you can’t create that thing, then you’re not a designer.
You might, however, be a researcher or strategist. And while this might sound as if I’m putting them down, I’m not. In fact, I feel that the constant push to make designer also responsible for research and strategy devalues both roles.
4. Empathy is (hopefully) not your job.
Empathy is not the unique domain of a designer. Literally everyone involved with building a user facing product should have empathy for the user, or they’re doing a bad job. If you genuinely feel that empathy is your sole domain, you might need to develop some.
5. On Job Titles
User Experience Designer is a terrible title because User Experience is a deliberately vague phrase that obfuscates what designers do, and allows everyone else to abdicate their responsibility for the “experience.”
There’s a cliché example that to create a successful restaurant, you don’t just design the menu, you design the experience. This is true, but most of the time, the person who designed the menu is not the person who created the menu, cooks the food, picks out the plates, or designs the lighting and acoustic environments. I prefer the term product designer because those are the things I’m creating – products – just like I work with product managers and product developers (and yes, that’s a real title, meant to differentiate from developers working on infrastructure).
An experience is a nebulous, vague thing with no specificity designed to generate importance via obfuscation. People don’t use an experience. They use software via a UI. They touch physical devices. They play games. They eat at a restaurant. Our job titles should represent the work that we produce, not a sticky-note driven cliché.
I’m now a Senior UX designer for Amazon, working to help 3rd party sellers succeed on Amazon. My goal isn’t to make them feel like selling on Amazon is something they must do. I want it to be something that the love doing.
I’ll add updates for my Indeed work when I can. I recently rewrote a the code that creates my Work pages to use section-level templates, instead of tedious copy-pasting of code.
I recently added a project where I redesigned the inventory management UX of Destiny 2, my current go-to video game.
It’s a truism, but that doesn’t make the advice to never stop learning any less meaningful. It is probably the number one bit of advice I offer to anyone in regards to career growth.
For better or worse, I see designers largely reading and passing around UX and design-focused tutorials – they’re reductive, simplistic, and repetitive. There was a post on Twitter or LinkedIn (now lost to my memory) describing this with far greater wit than I could hope to manage:
Junior designers read Medium articles about design
Senior designers write Medium articles about design
Design leaders read articles about everything else
(Or something like this – bonus points if you can point me to the original post).
I’m not here to bury anyone who reads or writes a UX design article. I find value in them as much as anyone when they provide a new perspective on a problem and don’t just rehash arguments or present false expertise. It is far more critical, in my opinion, that we embrace the fact that UX roles are multi-disciplinary by nature, and expand our knowledge base outside of our core disciplines.
Learn new tools. I don’t mean learning Figma if you’re in Sketch, or Sketch if you still design in Photoshop. I mean: learn to use a tool that completely breaks the metaphors you’re used to. If you’ve never done it, try to learn a 3D modeling program like Blender (or Cinema 4D, Maya, etc) – and discover how difficult it is to throw out your habits and preconceptions and learn an entirely new toolset.
Learn about your company’s business. What is its language? How does your company make money? How does it make decisions? How does it plan to survive another year or decade (or century)?
Learn about biology, sociology, psychology, and anthropology. How do people grow? How do our bodies change as we age and does this change how we interact with the world around us? How does this change, based on a person’s place in society?
Learn about education and pedagogy. How do people learn? There’s no single answer, as you hopefully know, but there are many theories about the best way to teach different subjects to different groups. On any design task, we can only reduce complexity so much before the task cannot be completed. At this point, how do we educate users on the complexity that remains?
Learn. But don’t worry so much about learning about UX.
Following up last night’s experiment, here is what I accomplished in one hour of wireframe. I focused on a single core flow – defining who is cooking the meal and how it could work. If you like this idea and can pull it off, you have my permission to steal this idea. Just do a good job and give me credit.
This is a bare shell of a small feature-set within the apps. But, I think it shows the potential of re-thinking how we consume recipes and cook with our families and I hope that something like this arrives in the future.
Timekeeping: My initial notes and sketch stayed within the one hour time limit, if you ignore the fact that my Wacom tablet and Photoshop had a disagreement that required troubleshooting and a reboot. I spent another 30 minutes or so typing this up.
The basics of a recipe app are pretty well defined at this point. Virtually every one contains a list of recipes, with the ability to search, sort, filter, and favorite. Each recipe contains an ingredients list and the steps needed to create the dish, and most include photos and secondary data such as tips, timing, and common substitutions. They’re literal digitizations of your parents’ or grandparents’ file of recipe cards. The better apps offer digital-native features, such as the ability to generate shopping lists and may have a video of someone following the recipe, but those are the exception.
Let’s think of some scenarios for a family cooking app that takes full advantage of a digital platform, specifically an iPad. Knowing how my family cooks, and others cook, there are a few common scenarios that occur:
First: the “rushed parent” scenario. I have little time, and only the ingredients on-hand to create a meal. This is largely solved by a large recipe database and good filters.
Second: I’m the primary cook, and I’m preparing a meal with multiple dishes. At the extreme end, this is someone preparing for a large family’s holiday meal. Multiple dishes need to be prepared in a sequence that allows me to make the best use of my time.
Third, I’m the primary cook, but I have a helper in the kitchen today who is less adept. I need help dividing the tasks appropriately so they can be a part of the meal without putting themselves (or the meal) at risk.
No, meals aren’t people, but let’s create some axes anyway:
Single dish vs multiple dishes
Single session vs a multi-day affair
How comfortable is the person in their ability to successfully cook this recipe?
I’ve never cooked before
I’ve never cooked this recipe before
I cook this recipe regularly
Is the cook capable of doing everything?
I have no limitations
I don’t know how to do something
I can’t do something…
…because my hands are full (or covered in something)
…because I have a physical limitation (such as someone with arthritis kneading dough by hand)
…because it’s not safe for me (a young child using a knife or stove)
How much mental power can you devoting to cooking?
My full attention
I’ll have the occasional interruption
A knock at the door
A crying child
I will be constantly interrupted
I have ADHD, or am otherwise not ‘neurotypical’
There’s a lot going on around me
Because most recipe apps are little more than a collection of text files, they can’t handle these problems well. It’s assumed you’ll read and absorb the recipe ahead of time and make sure you’re planning things out in advance. Additionally, recipes themselves are often written to encourage you to do large amounts of prep work up front, regardless of if it’s a quick stir fry (where this is important) or a slow braise (less so).
They also lack common definitions. If you’re a new cook, you probably don’t know the difference between a simmer and a boil, and if it’s your first time baking bread, do you know how to knead dough?
It’s easy to get lost in the steps if you get distracted for any reason, largely due to the design to optimize for page count even if you’re not printing the recipe.
As a part of the app, allow for the creation of users who may have different skill levels or specialties. Each recipe must be broken down into steps, with metadata for each step that denotes what is required for that step from prep, skill, and equipment perspectives. Allow for the combination of recipes into a meal.
Use those three pieces (distinct users, step metadata, meals) to create a step-by-step flow that focuses on appropriate division of labor and just-in-time prep. Thing about it as Lean Cooking or Agile Pastry.
Within the presentation layer, ensure the timelines are built so that no user can get too far ahead, and that the display is limited to only what is necessary for that step. Imagine a “presentation mode” for a recipe where each step is one slide.
Assume that the user cannot touch the device with their hands. Any action – whether it’s to go to the next step, get info, or start a time, will be voice-accessible in this mode, by any user.
I’m trying a new strategy for generating and exploring experiences, based on the idea of speed painting – a part of the warm up and exploration process of artists where they strictly time-box themselves and try to generate a larger quantity of work at lower fidelity, and not worry about specific executions later.
If we’re being honest, it’s glorified sketching.
If we’re still being honest, this is also pretty similar to the idea of a whiteboard challenge that designers are given in interviews. That’s ok, though.
My goal is to regularly explore product ideas that bounce around in my head, and experiment with different techniques, such as Persona Spectrums that I find interesting. I’ll take 1 hour to work through definition and discovery, and another hour to put that into wireframes. If I like the idea, I may continue my explorations into actual mockups or prototypes. My first idea? A family cooking app for the iPad. I’ll spend 1 hour on each of the next two days, and see where I get.