Note: This is an old post and may or may not accurately represent my current views, current technology, etc.
Project managers have extremely different roles depending on the company. In some companies, they create high-level flowcharts, define the feature set, and split it into the primary screens. After that process, an app for posting photos might look like this from a high level:
The designer sees each of the screens that need to be created and thinks, “How can I make these look amazing?” He or she designs the core screens in Photoshop and creates a set of design guidelines for the developer that explain the fonts, colors, etc.
The client developer integrates with the end points, creates each of the screens that has been designed, and ensures the basic “happy path” works.
The functional tester verifies every screen, tries images of various sizes, tests connections of different quality/speed, runs it on several devices, and ensures nothing crashes.
Everything should be great, right? You’ve got someone dedicated to managing the project and keeping it on schedule. You have a designer who is focused on making everything look amazing, taking into account factors that most developers won’t notice. You have a platform developer working to make sure the features are all supported and scalable. The client developer implements those features and makes sure they match the designs. You even have someone testing the functionality of the app from the user’s perspective, which is frequently a gap at startups.
So what’s wrong?
Here’s the feature set as crafted by the team again:
And here’s the feature set as required to handle all the states:
The problem is perspective. Here’s each person’s perspective
- Project manager: Feature list, gantt chart
- Designer: Primary screens with ideal content
- Platform developer: Data organization, end points
- Client developer: Screen implementation, end point interaction
- Functional tester: Crashes and strange behavior
What they’re likely missing is “the other state.” They’ve dealt with the ideal state in each case because that’s the one we see the most, but it’s only part of the user experience. Every time you look at a screen (regardless of whether you’re the PM, designer, developer, or tester), you should ask, “What’s the other state?” If the user enters invalid credentials, what does that look like? It’s easy to handle the ideal state for the feed, but what about the loading state? What about the failure state? You know what the friends list looks like, but what about when the user doesn’t yet have any friends?
The other state manifests as the loading state, failure state, empty state, and more. It’s the responsibility of everyone on the team and getting it right is a requirement for your app being great. It’s no good for the PM to say, “We didn’t account for handling errors, so we don’t have time in the schedule to do so eloquently.” It’s no good for the designer to say, “I designed the screen in the ideal state; it should be easy for the developer to make the empty state look good.” It’s no good for the platform developer to say, “I didn’t have time to create a combined endpoint to speed up the API response and get the loading indicator off the screen sooner.” It’s no good for the client developer to say, “The spec didn’t talk about loading and the endpoint is usually fast, so the screen is just empty for a second or two.” It’s no good for the functional tester to say, “The edge cases weren’t in the spec, so I just made sure it didn’t crash.”
Always ask, “What’s the other state?”