[[Notes]] - Topics: [[Design]], [[Productivity]] - People: [[Marques Brownlee]] - Source: https://www.youtube.com/watch?v=-OpUg0GDrII --- ## Summary - The main things to consider are user expectation and excellence of our offerings. - Time is a precious resource that must be managed and it is important to make sure our materials are available on all supported surfaces. - It's also important to eliminate legacy implementations or making it clear that they are legacy and should be avoided. - We have to streamline how users discover and understand our offerings, and should use the usage metrics to determine what components to offer or showcase. Not unlike how a big-box retailer (e.g. Home Depot) would present products for certain anchor pages on their website. - [[In the pursuit of greatness, do not fail to do good.]]. ## Transcript January 29th. 2023 1015. AM Watching. MKBHD review for pixel watch. Do things already. Jump out at me that I think are pretty interesting. Not necessarily about the pixel watch but just production in general. The first one was when Marquez talked about watch bands in that for generation one. You probably want to get the watch bands, correct, because people will be purchasing accessories, third party, watch bands. Throughout the years and you don't want the future version of the product such as the pixel. Watch to three, four, to be incompatible with the accessories that people have purchased in the past. This is in unavoidable but you want to kind of delay that for as much as you can. So there is some sort of ideal or acceptable period, where something has backwards compatibility for a certain Amount. I think the company that perhaps does this best is Apple notably how backwards compatible their iOS software is Not only that. They don't change the form factor of their phones. Very often, which means you can use a last generation case for a couple of release cycles. The other notable thing from this review video that I picked up was The idea of battery life conservation. This is something that we don't have to think about if we build applications for desktops because For the most part. They have significant enough battery to Run. Whatever a website has to throw at them. For the most part and for more heavier applications things, like, Adobe Photoshop Figma, etc. People just accept that these are heavier applications and they manage the batteries on their own to match. However, for wearables, where battery life is a premium, you have to be mindful of how often. Something runs or executes, that may Impact battery life. So how can this apply to? The work that we do. How can we think about? One of the most crucial resources a user may need, or think about And, How? Our feature, set, may impact and potentially hinder. That resource. From a productivity perspective. The equivalent of. The importance of battery life would perhaps be time. Time. And patience. The longer something takes to do. The quicker, the patients of the user runs out. Therefore, we have to optimize to make something as Intuitive as possible. We have to optimize for time. Time to completion, time to execution. Time to understanding. We must prioritize. Perfection for the user over profession for ourselves. It is okay if the experience. Internally. Is imperfect. It is less. Okay. If the experience externally is imperfect That is our responsibility. Another issue noted by Marquez about the pixel watch is that the Fitbit features feel like a bolt on. Feature. For something that is so software driven. Feature sets, that feel almost like an operating system level. Function. Should feel cohesive. How it applies to us is. For our main offerings, that being components and other mechanisms for building UI. It should feel. Like, Anyone should be able to use it within, The domains that are supported. So for example, if you're supporting surface A and B anyone from surface, A and B should be able to see, mostly use your stuff and transition their creations from surface. A to surface B With the assumption that they are using your things and portable materials. The general theme for, that would be compatibility compatibility would meet user expectation. The other aspect of this as it applies to our work is Availability. For the things that users demand or need or expect. Those materials should be available. And the materials should be manifested in a way that Best suits. The expectation known or unknown, by the user that is what makes something intuitive. When it is disjointed, it is Extra frustrating for the user because they feel like this is basics stuff and the basics stuff should be Figured out. And this provides some sense of uncertainty because if the basic stuff isn't figured out what else is in figured out, To accessory connected to. Related to software. Another thing that Mark has pointed out is If there are multiple services that do similar things, that makes the experience you'll extra disjointed. Why is it that? Something. That is working on my device. That should be compatible with service. A, not be, but rather it is using service B instead. So the more versions you have of the same thing, the more confusion there is For that particular thing. This is compounded for every single instance, you have How it applies to us is. The. Duplication of similar components. Because of that, a user doesn't know which one to use. Trying to resolve all that in the single sweep is difficult because it involves Migrating and touching lots of legacy files to bring them. Up to speed. The easiest. And perhaps most impactful way to do this is to declare That from this point forward, please use this new thing, all prior instances are considered deprecated. And to make that clear, note, not only in your messaging, In your announcement, but also in any materials that a user may double upon if they try to reach for a legacy version of that component, This applies to code comments, potentially? The naming of certain files. And of course, documentation This information has to be repeated multiple times. Therefore there has to be upkeep for. The multiple instances of these repeated. Informational snippets. That is the cost of keeping the legacy implementation alive. While we promote the new thing, this costs can be avoided if we refactor the old legacy components. So that every single instance uses the new one. However, because we cannot we must pay the cost of Maintaining up to date information. From a Android phone perspective. The best example of this is if you purchase and use an Android phone that is by Samsung Or. A non-google manufacturer. You will most likely get a duplicate version of was appears to be a basic application. You may get two photo apps to calendar apps to contact apps etc. This is because the manufacturer. Thinks that Their version of the application is superior. Versus the stock Android one. That is supplied by the operating system. Whatever superior means to them. I don't think this is ever acceptable, but it becomes tolerable over time. When users just get used to it. If you use a Samsung device for many years, you just come to expect that. The phone will just ship with duplicate software. One is a Samsung one. The other is the Something else one. This is made worse when phones are branded and or locked by carriers because then you have the carrier infused bloatware. I don't know how much this happens these days but it was certainly a problem. Over five years ago. All this goes to saying, That. You should make it your mission to reduce duplication. When it comes to user consumer bowl materials, as much as you can. Every single. Resource you release from documentation to componentry to. Utility. Must serve a purpose. And, No other offering should feel like it. Competes with that purpose. If they are similar. Then that distinction needs to be made clear. The best example as it applies to us is. The offering of a collapsible component and an accordion component, A collapsible. When it comes to component libraries is often a Unstyled. Purely logical mechanism for hiding and showing You, I and contents. Accordions use collapsibles as part of their hide and show mechanism. However, accordions, provide you I and styling when it comes to headers Arrow indicators, potential borders, etc. The line between these two, Is very small but it is there. So, How can we promote these things? So that folks do not get confused. The best way to do that is To. Showcase the components. In a way where they are categorized in different as different things. Things like collapsible clickable. And other low level utility very engineered driven components should be classified as such and should most likely be Listed either. Lower on the page where it is less. Lower on the page where it is less likely for someone to see or to be listed somewhere else entirely. When the user lands on the listing of components, they should be graded with components that they will most likely use. This is similar to how if you were to land on Home Depot. And online store with an offering of tens and thousands potentially hundreds and thousands of products they custom tailor each page. So that hopefully you as the A customer are able to find the tools trinkets hardware etc that you need when you go to that page. For example, if you're go to a page, dedicated to power tools, or even drills, you should be presented with At the forefront various drills from various manufacturers. Sure they'll be duplicates etc, but the first thing you should see are drills things that are adjacent to drills or related to drills are still there, but involve a couple of more steps for you to find such as drill bits batteries. Potentially work. Benches clamps etc. Those are still available. There are still part of the Home Depot site, but they are not presented as forward as the main thing which are drills, For us, we need to take the same approach. The components that we offer users should be the ones that they will most likely use as part of their day-to-day. We have this in the form of component metrics, we know what are the most common components people will need? We can craft the Information architecture to match. One thing to note is that we should not Spend too much time or over index on trying to make this perfect. We don't have nearly as many things as something like, Walmart Home Depot etc. We have at most 100 things. So we should work within the scope of that. Limitation, that should be a strength, not a weakness. And we should approach this exercise. By ignoring the current technical limitations that comes with attempting to build these pages and to connect these pages together. To summarize. The main things to consider. In regards to the frustrations, Mark has expressed with a new pixel watch. Touch upon themes that are Similar or directly related to the type of work that we are doing. Those themes can be distilled to. User expectation. And excellence of our offerings. The most precious resource that we need to manage within our space is time. Time for the user. How fast? Or rather. How long does it take them to get the job done? Using our materials? And the swiftness of that depends entirely on how quickly they understand the material. Or can infer the usage of the material and the availability of our material. Things that can impact this negatively are if we have multiple offerings of the same thing such as a select component. Therefore causing confusion as to which select to use for what case? The other is, if our components Are not available on all surface areas where users expect them to be. So, we need to make sure our things are available on all supported surface areas where the design system is expected to perform and to either eliminate legacy implementations or make it clear that all prior implementations are legacy and users are expected to use the new singular version moving forward. That is the path that we will take due to current resourcing of the team. And because we're making a choice for legacy materials to Continue to exist. We must then communicate very clearly that these materials are legacy and are to be avoided. That is the cost we must pay. For keeping those things alive. Lastly. We have to streamline how users. Discover and understand our offerings. From the system especially when it comes to components or concepts. That are similar but intentionally distinct. The best example would be. Collapsible and accordion, They both do similar things. But a collapsible is a smaller atomic. Functional piece that accordions would use. One way to think about this would be to approach it like how a large e-commerce platform would. Approach their website. If they had. Tens or hundreds of thousands of items. How do they organize information in a way? That makes sure that users can find what they need and they are able to find auxiliary or adjacent items related to their main Thing. And we must approach this exercise. With the acknowledgment that we will never have as many things as a large online retailer, our offerings would Span, probably at most to 200 elements. From components to tokens etc. We should use this as a direct strength and not as a Weakness. And how we know what components to offer or showcase. Should be based on what users need the most for their day today and we have all this information in excruciating detail from our usage metrics. So with that, I think we have identified. The. Themed and approaches of work, we need to do. We just need to get it done. To get it done quickly, and to get it done. Well, Always remember. In the pursuit of greatness do not fail to do good.