Junior designers, stop designing for the happy path
In design, the happy path is what happens when the user does everything exactly the way you expect them to. Although this can happen, it won’t always happen.
One of the most common mistakes I see in portfolios from junior designers is that they often show too much — and too little — simultaneously.
One unfortunate reality of the many design boot camps out there is that they seem to encourage students to design entire apps or entire web pages for fake businesses.
Now, before we continue, I am a big supporter of design boot camps. I believe that there is a lot of work to be done to improve many of them, and I also feel like General Assembly is a borderline criminal enterprise. The most unprepared students tend to come from there and I have met more than a few that haven’t been able to find jobs even years later. Regardless, I think that boot camps, in general, are filling a very real gap for a career that lacks college programs. I personally attended DESIGNLAB and a few courses at BrainStation, both of which taught me a lot, although neither was perfect.
The problem with many student projects is that they take on too much. You don’t start your first job and get presented with the task of designing an entire app. You also don’t start right off redoing an entire website (in most cases). Projects are broken down much more granularly, and it’s more likely than not that you’ll be collaborating with other people throughout the project.
Many junior designer’s portfolios (including my own, when I started) will show the concept for an app, along with a chronological checklist of research methodologies, and then final designs, that often don’t adhere to either Material Design or Human Interface Guidelines, and would be unjustifiably complicated and expensive to build, for no good reason.
When I talk about the “happy path” issue, I am referring to these final designs (or the wireframes). I often see designs that show a user effortlessly signing up, making an account, accomplishing a single important task with no hiccups, and then going on their way. When designing in the real world, you don’t get to just account for that happy path. You also have to account for a plethora of other paths. And I can bet you that interviewers are going to ask you about some of those paths when you show these designs.
Some questions to ask yourself — AND DESIGN FOR:
- What happens if the user exits the app and then reopens it?
- What happens if the user has airplane mode on?
- In the case of apps with populated lists, what happens if the user doesn’t have any “items?”
- In the case of apps with the ability to buy things, what happens if the user doesn’t have a payment method on file?
- In the case of apps with registration flows, what happens if the user skips a section and then wants to go back?
- In the case of apps that load things (pretty much all apps), what does that loading look like? And what happens if it fails?
This list represents some of the more lightweight questions you may be asked by a product manager. The reality is that complex APIs and limits on front-end logic can require you to solve even more complex situations.
A few that I’ve come across.
- What if it’s possible to save some rewards for later, but others will be automatically applied? How do we show the user which they can save, and what UI component makes the most sense for saving and activating rewards?
- What if the user runs out of pre-loaded funds. The way it’s built, we will charge their default payment method? But how do we communicate that with them so they know?
- It takes a long time to load this screen, what can we show the user first to allow them to make corrections before the rest of the screen finishes loading?
These difficult questions, in addition to fleshing out realistic designs, also challenge you to make compromises. Fake projects don’t have to make compromises, but it would be so much more impressive if they did. Very often I am faced with decisions between including some piece of information that I think the user would enjoy having or increasing the loading speed.
I’ve looked at a lot of portfolios. I guarantee if I saw some empty states, error states, or other interesting cases accounted for, I’d look again.
