 design strategy for constrained productivity tools. So, we're gonna talk about something that I've discovered by applying different approaches towards designing for such tools and I just call it a strategy because it sounds like more strategic, but it's something that I actually ran it by accident more or less. So, first I would like to say hi, my name is Stefan, I come from Bulgaria, which is in the north-southeastern corner of Europe and I work at Infragistics, a New Jersey-based company as a senior user experience architect, where our main business and what I've been mostly involved in are a few toolkits and libraries with UI controls that are actually more or less cross-platform. They are from RichKlan, to Mobile, to Web, like all kinds of different tooling that we offer to developers to build better and faster user interfaces with. I'm also involved in the product line of developer productivity tools, which are tools for improving the productivity of developers when coding in Visual Studio and I'm also a person who really enjoys talking about user experience, teaching user experience. We have a few courses in Bulgaria even, so that's actually also what brought me here and that's the other me, maybe. Did some of you have cookies this morning with the coffee? So, do you like cookies first thing maybe? Okay, I like cookies, I like to eat them and I like to bake them and make them at home and these are some of the types of cookies that I've tried preparing and I've experienced myself. So, I'm gonna use cookies today as a really kind of a metaphor for the talk and I don't know if the organizers were expecting this, but for three days now we've been having coffee and cookies so maybe next time I'll talk about coffee. So, cookies will be something that will be kind of a reiterating over the course of the session, but first I wanna take a brief, yeah, this course and a detour and tell you about constraint productivity because that's something that sounds maybe too esoteric or too exotic, I don't know if you have a good understanding of what such tools are, but in design we are well familiar with the concept of constraints. I think it was mentioned yesterday during some of the workshops or maybe even the keynote and constraints are those tools, physical, usually characteristics of a product that are there for a purpose and that's the purpose of not allowing the user to do what he's not expecting to be doing with the product. So, if you look at this example, the pumps at a tank station, I don't know if you've kind of really head dialed eye for the detail, but usually the gasoline nozzle is very narrow compared to the diesel one. The diesel one is much wider and that's a constraint that's there for a purpose because if you're able to plug diesel into your gasoline car and fuel the tank, then you're breaking the engine and it will not, like you have to replace the engine. Whereas if you do it vice versa, yeah, you still cause some damage on the car, but at least the engine is usually intact, like you just have to like get rid of the fuel, putting gasoline, maybe change a few small things and the car is good to go and that's the purpose of constraints. It's something really dangerous and you really wanna make sure that there is no way that your user makes that mistake that could be there in the product potentially. You put a constraint that's actually preventing the user from the wrong actions. And productivity, I really liked how even Steve today in the morning touched on this topic a bit. It's usually believed to be the ability of some, I think it was Shiva the God with the thousand hands or a hundred hands, at least that's how our culture, like usually one of the first things we associate India with and that's how productive people are depicted usually as people who do a hundred things at a time, which is impossible. For a man, I can guarantee with myself, like I know women can do at least a few things at the same time, but nobody can do a hundred. And even if you Google productivity, you see these kind of pictures. I would argue that productivity is actually being able to do one thing very focused, but have the results of a hundred different actions. And that's what really productivity tools give you. Because if you think like for an example, productivity tool, which is Google Forms, has anyone used Google Forms before to create surveys? Okay, that's a perfect example of constraint productivity tool because sorry for the language, it's in Bulgarian, but anyways, you get the picture. You're able to select between five or six types of questions and you're really constrained in your selection. You cannot just create any kind of a survey question. And those questions usually differ only by the way people can answer them. So you're very constrained and these constraints keep you in focus to achieving your goal, which is ultimately making the survey in a matter of maybe an hour, sending the link and waiting for the results. If you have played with this kind of a tool and I don't know if you've gone into customization, like changing the theme or maybe looking at what you could, kind of how you could change the visual appearance and aesthetics of the tool, but for teams, you can just pick a picture and a color. You cannot change the font size. You cannot change the font family. You're like very, very limited in what are the possible actions. And since these limitations make you more productive and make you get to your goal faster, that's the perfect example of a constraint productivity tool. So coming back to cookies, I already saw who of you are cookie monsters. Can you have your hand up and keep it up again? People who like cookies, people who also baked cookies and like baking cookies. Okay, so lesser, but still some people kept their hand up. I'm asking this because if we are the person who makes the cookie, we really have to know who are we making the cookie for. Because some people like chocolate chip cookies, other people like gingerbread cookies and you have to know your audience. That's the first rule of user experience. Well, how does this kind of go into the field of constraint productivity? Well, if you wanna know who your cookie user is, one way to do this would be to go in the store, stay on the cookie azo for like one day or a few hours and just observe people who are buying cookies, ask them a couple of questions and you have your access to your users, right? Right, but also kind of not 100% correct because if you pay more attention and read maybe what's written on the box, like that's one cookie box, I'm not making any advertising here, you see that it contains six servings per container. So if you bake the cookies, did you bake them for yourself only or you bake them for the family, for friends visiting over, probably you did. So this is the same thing. You buy one box, which works for six people, let's say, and you might be buying the box because you're expecting guests for dinner or because you're having a family dinner together with your spouse and children. So now that we know this, we know that there is not only the primary user of our cookie who buys the cookie box from the store, but we also know about another group of users who are experiencing our product, the cookies that we have produced, through the hands and eyes of somebody else who bought the cookie and brought it to them. And I call this group of users secondary users. So if we look at a typical constraint productivity tool, and I'm using here an example that I've been working on, we've been building this library of data visualization controls, which we sell to developers. And we know who the developers are buying those products. To some degree, we know that they're building some sort of a dashboard like this one here. However, we don't know who the user of the dashboard is and what are the type of people that use the dashboard. But one thing we know for sure is that those two groups have very different user needs. The developer might be interested in documentation that it's there for him and he can use in order to be more productive. He's interested in defaults that work nicely out of the box so that he doesn't need to configure a lot of covers. He's interested in a lot of things from his own point of view. But the secondary user, who is a person looking at the dashboard, needs to know about the clarity of the information. It needs to be easy to grasp and to understand. He might be interested also in concepts of navigation, how intuitive it is. So the user needs of the two groups are very different. And if we look at another example, I'm using Indigo Studio Cloud from yesterday. Those of you who are in the workshop maybe are more or less familiar with it. It's actually a cloud service that allows you to create usability studies with the prototypes that you have already built on your desktop. So you sink there and you start creating the study. And if you're the person designing the tool, you're thinking about what are the steps that this person would need for creating the study? What is the flow that he records different tasks and provides them to users? But at the same time, you're aware that once the user experience researcher is done with his study, he's just gonna click on send or share a link with people and he's gonna distribute it to his population of users. And that's when the secondary user kicks in as the people who are actually taking part in the study going through the task and they have another set of requirements like, is the task there when I need it? Can I kind of understand what I'm being asked? Do I know how to complete the task? Or do I know how to start it? Because maybe the timing matters. Whereas the designer behind this study or the researcher who created it is interested in a very different set of goals. So my first kind of advice would be if you're building such tools which are putting constraints to make people more productive, always bear in mind that besides the primary groups of users that you're well familiar with and expecting to meet easily, there is usually also a secondary group of people who are less obvious but are definitely not less important for your design. And if we talk about cookies, every cookie is made from some kind of a dough. So when we're building such tools, it's really about knowing how to combine features, how to combine requirements in the way that they really provide a comprehensive user experience in a way for the end user. And if we're doing this for cookies, we usually follow a recipe because in the recipe we not only know the right ingredients but we also know the right amounts so that the dough is like well-made. And how do we apply this to the concept of constraint productivity? My personal experience has been with the application of the card sorting technique. How many of you are familiar with it? Okay, the majority. So that's a technique where we actually take cards with features, one feature per card and you lay them out on a table, ask your participants in the workshop to arrange them in order of priority top to bottom. And what I've identified is that when you're usually working in constraint productivity tooling, the set of features is not like 20, it usually can go up to a hundred. And it's very hard to have people, no matter how smart they are, to organize and prioritize a list of a hundred things. So what I've seen and what I've basically done based on my experience is to ask them first to split this dough in different bowls or to tell them you have these hundred features. As a first step, let's think about the critical features about the important ones and the ones that are nice to have and are not necessarily needed to be part of the core experience of the product. And once people make this kind of arrangement, they usually are much more at ease in order to do the card sorting and order them by rank of priority. So usually that's something that people call bucketing. I don't make cookie dough in buckets, so I use the concept of bowls. But if you wanna make different types of cookies for your different people that you're expecting over for dinner, you can just split the dough in three bowls and add chocolate chips to one, nuts to another, and maybe raisins to the third one. So you can address the diverse needs that people might have in terms of taste. One important thing about organizing these kind of workshops is to involve and to invite different stakeholders and different users. Of course, you have representatives of your primary group of users, of your secondary group of users, and some stakeholders from the business perspective because they also bring very valuable input when it comes to card sorting. So involving a group of six or seven people is what I find to work best. Larger groups never get to a consensus. Smaller groups are just too focused in one way or another. But make sure that mentioning that this is kind of a workshop setting. You never do it in isolation. You never do it with your fellow designers. You do it with representatives of the users and business stakeholders. And we have the dough. We probably need it. We have to roll it out in order to cut the shapes, right? That's the next step of making cookies. So how does actually cutting make it into designing tools and designing software? Well, is actually anyone familiar with the Pareto principle or can they like say what it states roughly, Pareto? That's a principle that's probably valid across anything because it's just some sort of a statistical bell curve that's just there because of human behavior. And I applied to design here because what I find out is that if you take those prioritized buckets and you see them as one whole thing, usually you need just 20% of the features there. And that's when you make the first cut. So you don't cut the dough, you just cut the features, see what's the top 20% tile and choose those features as your core features for maybe the first release of the product. What I sometimes do is to make another cut. So those 20% of the features, I make a second cut. So maybe it's one, okay, five minutes left. So this one feature is gonna be, or if there are more, is gonna be my really core feature which is the highest priority feature. And that's the feature that's gonna get the biggest visual footprint in my layout and design because that's what's really the core of the product. There are usually three to four features, maybe five, not more than that. The others are complementary features that I tend to not really hide in the design but I give them, let's say, secondary placements and locations because those are things that not all of the users will be actually needing. And parental principle, the first time I read about it in terms of software was when researchers at Microsoft actually did some sort of a large-scale study and they found out that in Microsoft Word, 80% of the people were using not more than 20% of the functionality regularly. And they got wondering, why then we have so much functionality in maybe 10 toolbars one under another whereas people don't really need all of this at a glance and that's when in 2007 they came up with the concept of the ribbon and hated or loved it, the ribbon is the perfect example of the 80-20 rule because the ribbon gives you only 20% of the functionality unless you expand and get to like the more detailed functionality. So in order to cut the dough, it's also important if you bake cookies not just to cut it randomly because if you cut it randomly, you have a lot of leftover that you have to knead again, roll it out and cut once more. So you go through a lot of iterations of cutting in a way. However, if you optimize your cutting strategy, you will have less leftover each time and maybe instead of going through five or six iterations, you only go through three or four. And that obviously saves a lot of time. So talking about saving time and productivity, I wanna go in the last section which is really reducing the cut-off leftovers in terms of, of course, building software. And the one thing that I want to remember and I would like to ask you to remember from my talk is that the one critical piece of constraint productivity tools is about picking the best defaults for your product because defaults are really what makes or what glues the experience together. If you're looking at something as simple as this progress spinning indicator, you can have easily 20 types or 20 different parameters to configure. And if you pick your defaults correctly, your users will, or actually your primary users will never have to really tweak all of those 20, maybe just one or two. So it really becomes critical regarding productivity for them and also it assures a very clear and consistent understanding of the interface for the secondary users. So once again, picking your defaults is probably the one best choice that you can really invest a lot in. And it could be also something different, like maybe in a design tool, picking the default interaction when user clicks on something, like what happens next? Does it ease in? Does it slide in left to right? Or it just fades in? What's your best default? Sometimes the answer is not so obvious, but of course what I found to work best are two strategies. One strategy that I apply is called, or at least I call it the simplest solution, which usually I have my different kind of design ideas and I just pick the one that has the smallest visual footprint. So if I'm choosing between a tool bar, between a tool tip and between an inline message, I would choose the inline one because it's just less ink on the screen. The other strategy is something that I think Steve also touched on the first day and that's the strategy of using an alternative scenario, which is very similar. I think he used the example of using or selecting, let's say, a set of dates or a span of dates for airplane booking where actually you are asking how users would do the slicing and dicing of data regarding dates for choosing from which to which date they wanna see analytics information about. But since that was a very focused domain, they kind of took another approach which achieved the same task, but just for an airline booking which everybody's familiar with. And the thing I wanna wrap up with is really that cookies are for sharing. So if you made cookies, you shared cookies. You never make them and have them only for yourself. And sharing cookies and sharing food as an experience is something that we're very familiar with. It's very personal and it's kind of sign of a friendship in a way. So when you're kind of building these things for software, it's really important to share this process with your developers who eventually will be working on the feature set because if they're involved in the card sorting, if they're involved in each step, maybe just as an observer, they're much more committed to your design rationale. They understand it and instead of having a group of people who are just being opinionated and arguing every choice you make, you have people that actually are protective for your ideas because they were there when the decisions were made and they are well aware of the reasons because of those decisions and why they were made. That's one example. We were designing, or we were coming with concepts for pie charts. The watermelon in the middle is like something circular that people had the task to optimize the way it's cut. And that was a very similar approach to optimizing slices in pie charts. Everybody enjoyed it and there were people from the primary user group, the secondary user group. There was one developer on the team to be working on the feature and of course some business stakeholders who all gave their ideas and this way we got like a common understanding and a more involved product team. So I would like to thank you and do we have some time for questions? So if you have any questions, find me in the coffee or lunch breaks, just approach me and ask me whatever you would like. So thank you for being so patient and it was a true pleasure. I think that's it. The rest of the week. We'll see you next week. Bye. Thank you. Thank you. Thanks, ladies. We'll see you in a bit. Bye now.