Reducing Problems
Outlines also come in handy for answering a key design question: are these actually the same thing? A huge part of design is figuring out what the product really is and how all its parts fit together. Can two needs actually be served with a single feature? Is a certain feature trying to do too much, and would it be smoother if it were broken into more than one feature? Much of your personal style as a designer is defined by how aggressive you are in consolidating or dividing elements of your app, so be ready to spend a lot of time thinking about it.
Say you’re considering whether to include both tagging and multiple user support in your design for SnackLog. As you organize your outline, you find that they both seem to fit under “categorization.” That’s a sign they might be candidates for consolidation. Think about what, if anything, makes them different. They both require you to set up and apply labels to purchases. They are both things you might want to filter or search on while browsing purchases. Looking pretty similar so far.
There are a couple of multiuser support features you can rule out, because they don’t seem to belong on iOS—for instance, hiding one user’s purchases from the other users. iOS devices are generally used by one person. If there are multiple people keeping track of information with one device, they are very likely to be family members and don’t mind sharing information. Ultimately, it rarely makes sense to offer explicit multiple-user support in an iOS app. But if people really do want to share SnackLog, they should be able to just create a tag for each person and get most of the functionality of multiuser support. So these two features can be rolled into one.
So you strike down the idea of doing multiuser support, for two reasons. First, it would seem out of place on iOS. Second, you can get most of the way there with tags anyway. In fact, you’re not really entirely striking it down; instead, you’re rolling the two features together. iOS is full of this kind of feature problem reduction.
Also remember that sometimes what seems like a single feature actually needs to be split out into two or more dedicated features. Take deletion. At first it may seem that deleting all items is only a variation on deleting a single item. So maybe whatever interaction you come up with for them should be presented side by side. (Getting ahead of ourselves into actual interaction design, imagine a trash-can icon that, when you tap it, offers Delete One and Delete All buttons.) That would be kinda terrible. People delete single items all the time, but only rarely would they want to delete their entire purchase history. Both are deletion operations, but you need to design them in very different ways. As you revise your outline, you might move the Delete All feature away from the browsing functions and into a settings area. You might even stop calling it “Delete,” and start calling it “Reset,” to differentiate the two. Coming up with terminology that matches the way you think about features will help you design them.