Design Philosophy
All about the guiding philosophies we employ
Whether you realize it or not, you are constantly designing anything you build. It is an intrinsic part of creating something. Design is not just what something looks like. It's not just the colors and fonts. Design is how it works. When you decide to add a button that does a thing, that is design. You made a decision to add a button with an icon or a label and where that button went and the size and color of that button. Decisions are designs.
For a quick design crash course, we like "The User is Drunk" on YouTube. See also: Design Is Not Veneer by Aral Balkan
Consider different types of bicycles. A folding bicycle has a different set of design goals than a mountain bicycle. Things like weight, size, and tire tread are important and competing factors in helping the intended audience reach their goals. Because we understand that design is about solving specific problems, we must also understand that we can objectively compare the effectiveness of two designs at solving those problems.
Providing settings can be a way to make sure an app is accessible to a wider set of people with unique needs, but it can also be an easy way out of making design decisions about an app's behavior. Just like with problems of feature bloat, settings mean more code, more bugs, more testing, more documentation, and more complexity. Before adding a new setting, ask if this setting is about passing off a decision or if it's necessary to make your app more accessible to different types of people. Don't ask the people using your app to make engineering or design decisions. Settings should cater to competing needs.
Before adding a new setting, ask if this setting is about passing off a decision or if it's necessary to make your app more accessible to different types of people.
Where possible, rely on system settings rather than implementing your own local settings that may conflict with global ones. Instead of asking for information like location or someone's name, use portals to get this information from the OS.
Build for the "Out of the box" experience. Most people will not change your app's settings from the defaults.
Instead of tucking away settings in a separate dialog, think about displaying them in context with the objects they affect (much like how shuffle and repeat options appear near your music library). If your app needs to be configured before it can be used, use Placeholders where possible before using separate setup screens.
See also:
It's often tempting to continue adding more and more features into your app. However, it is important to recognize that every new feature has a price. Specifically, every time you add a new feature:
- The main function of your app becomes less immediately apparent.
- Your app's interface becomes more cluttered and harder to use.
- Your app gets slower, consumes more resources, and takes up more disk space.
- More code often means more bugs.
- More time is spent implementing this new feature, rather than perfecting an old feature.
Build specialized apps and rely on system functionality or other apps for additional workflow-adjacent features. For example, instead of building an image editor into a presentation app, make it obvious how to open images in an external image editing app.
Most people will expect to be able to use your app without reading separate documentation first.
“Manuals” from XKCD
Avoid technical jargon and assume little-to-no technical knowledge. Provide non-technical explanations instead of cryptic error messages. If something goes wrong, provide a simplified explanation of what happened and how to fix it.
Last modified 1mo ago