| Benedikt Meurer | 4385a56 | 2024-08-21 13:19:52 | [diff] [blame] | 1 | # Chromium DevTools UI feature checklist |
| 2 | |
| Benedikt Meurer | 4dc9c70 | 2024-08-22 07:23:32 | [diff] [blame] | 3 | [goo.gle/devtools-ui-checklist](https://goo.gle/devtools-ui-checklist) |
| Benedikt Meurer | 4385a56 | 2024-08-21 13:19:52 | [diff] [blame] | 4 | |
| 5 | Chrome DevTools is used by most web developers nowadays. In user interviews and |
| 6 | informal conversations web developers voice the opinion that Chrome DevTools is |
| 7 | great, but they have a hard time finding the right tool for the job. Naturally, |
| 8 | the Chrome DevTools suite will grow over time, as the Web Platform keeps on |
| 9 | growing. Without intervention, this will *clutter* the UI of Chrome DevTools |
| 10 | even more. This document here should serve as a checklist when new features are |
| 11 | added to Chrome DevTools' UI. |
| 12 | |
| 13 | Please reach out to [[email protected]](mailto:[email protected]) (PM) or |
| 14 | [[email protected]](mailto:[email protected]) (UXD) with any |
| 15 | questions and concerns. |
| 16 | |
| 17 | [TOC] |
| 18 | |
| 19 | In general there are some categories which are important to look at: |
| 20 | |
| 21 | ## Measurability |
| 22 | |
| 23 | We should be able to define and measure the success of a feature. Ideally, we |
| 24 | treat every feature as an experiment which needs to prove itself before it can |
| 25 | stay forever. (not literally with an experiment checkbox, but as a mental model) |
| 26 | |
| 27 | * Can we clearly state what our **goal** is that we want to solve? |
| 28 | * Can we formulate a **hypothesis/assumption**, how we believe our feature |
| 29 | will solve this goal? |
| 30 | * Can we **validate** this and see if our feature actually does what it |
| 31 | should? |
| 32 | * And finally, can we **remove/revert** a feature, if we see that it's not |
| 33 | used at all? |
| 34 | |
| 35 | ## Strategic fit |
| 36 | |
| 37 | Does a new feature directly support our strategy? Is a feature weighted against |
| 38 | our backlog? Does a feature help us in reaching our strategic goal? If not, we |
| 39 | should de-prioritize it. |
| 40 | |
| 41 | ## Relevance |
| 42 | |
| 43 | How relevant is a feature to our user base as a whole? |
| 44 | |
| 45 | Does a feature support one of our core developer journeys or is it related to a |
| 46 | niche area? |
| 47 | |
| 48 | * Are we over-fitting to a tiny niche part of our user base? |
| 49 | * From the perspective of the implementing team, each feature is super |
| 50 | relevant, needs to be discoverable and should sit in the prime UI. |
| 51 | * We as a product team should carefully choose which user journeys are our product |
| 52 | core and if a new feature adds distractions to these journeys or enhances them. |
| 53 | * Is a feature relevant for the mainstream of non-Google engineers? Or is it |
| 54 | mostly a Google-internal feature? |
| 55 | * Is it adequate to expose a feature to all of DevTools' users, even if only a |
| 56 | tiny fraction will ever use it? |
| 57 | * Should the feature be shipped to all of DevTools' users or rather be made |
| 58 | available as a DevTools extension? |
| 59 | |
| 60 | ## Potential impact |
| 61 | |
| 62 | Is a feature a life-saver or just a quality-of-life improvement? |
| 63 | |
| 64 | * We should prioritize impact for our users. |
| 65 | * Can developers live without this feature? How do they solve the problem |
| 66 | right now? What's the worst that would happen if we don't develop this |
| 67 | feature? |
| 68 | |
| 69 | ## UI complexity |
| 70 | |
| 71 | Is a feature easy to revert/remove if we figure out that it's not used? Or will |
| 72 | it stay forever in the UI and clutter it even more? |
| 73 | |
| 74 | What's the least amount of work/UI we need to test how a new feature is actually |
| 75 | used? |
| 76 | |
| 77 | Is this extending an existing feature or creating something new? Which (and how |
| 78 | many) other features are in its vicinity on the screen and panel? |
| 79 | |
| 80 | * We should favor solutions, which can be easily reverted or removed if we |
| 81 | figure out that a feature is not really used. Deeply integrated UI solutions |
| 82 | tend to stay forever. |
| 83 | * Instead of going *all-in* as the default, we should add features |
| 84 | incrementally and measure along the way if a feature is quickly becoming |
| 85 | mainstream or stays rather niche. Based on this the next iteration can |
| 86 | either extend the feature or further deemphazise it in the UI. |
| 87 | * UIs should not be overloaded. |
| 88 | * Avoid requiring major UI reworks if it is just extending an already existing |
| 89 | feature |
| 90 | * We shouldn't default to adding a new "panel" for every feature, just because |
| 91 | the feature team is looking at the feature in isolation. |
| 92 | |
| 93 | ## Placement and discoverability |
| 94 | |
| 95 | How many user interactions are needed until the user is using the feature |
| 96 | (without Command+P)? |
| 97 | |
| 98 | * Sensible thresholds: |
| 99 | * **< 3 interactions**: Very accessible, good if it is intended to be used |
| 100 | by most users |
| 101 | * **3 < 6 interactions**: Likely somewhere in a front panel, likely good |
| 102 | for most of the features |
| 103 | * **6 < interactions**: This is hard to find! |
| 104 | |
| 105 | The more often something is used, the easier it should be able to be opened. |
| 106 | |
| 107 | ## Target audience |
| 108 | |
| 109 | Which user type is going to be using this feature? How many of these users? |
| 110 | |
| 111 | Will this primarily be used while debugging production instances of web |
| 112 | applications (obfuscated code, no source mapping) or dev versions (local, source |
| 113 | mapping, source code available)? |
