Interaction Design Beyond the Interface Workshop

Editor's Notes

• #2: ** How do you feel cheer\n\nWelcome to Interaction Design Beyond the Interface. We have a great day ahead of us...\n
• #3: Part I - Introduction, discuss current state, discuss problems with current state, introduce our solutions.\nPart II - Learning who is on your team, Who can help you solve the problem and Determining what is the real problem. \nPart III - Learning who you’re solving for, and how to determine the information/content you are working with.\nPart IV - Learning how to determine information priorities, model the solution not the interface, and sell your solution to the team.\nWe have a load to learn, and keep in mind all the information and steps will be provided to you to take home with you so you don’t have to be heads down taking notes the whole time. These slides will also be provided to you. \nSo let’s start off with introductions\n
• #4: My name is Lis, and I’m a consultant in NYC. I wanted to put together this workshop as I was noticing more and more that the basis of my profession was being erased and overlooked. That basis is the ability to facilitate defining the real problem and coming to a solution without ever thinking about the interface. \n\nAnd that is what we are going to talk more about today. But first.\n
• #5: If we are going to spend the next 8 hours together we should get to know more about each other. \n• Who would call themselves an Interaction Designer? Would you call yourself a UXer? How about visual design, art direction? Development?\n• Who is still a student? - what do you expect to be doing in the work place?\n• Who has been practicing this for\n Less than 5 years\n Between 5 - 10 years\n More than 10 years\n• Ask a representative from each what they are hoping to learn from this Workshop? \n\nLet’s first start off by defining interaction design and the dyer situation we are currently in.\n\n
• #6: Let’s first start off by defining interaction design and the dyer situation we are currently in. To me interaction design is about designing an entire interaction, not just the interface of that interaction, but the entire touch point. \n\nSo when we look at Interaction Design in relation to User Experience Design we see something like this...\n\n\n
• #7: User Experience is really this overarching umbrella which houses all of these other disciplines. Interaction Design is a part of all of this... and to me it is a subsection that looks at one to many moments of contact between a user and a companies system.\n\nInteraction Designers work with insight from UX designer to come up with the detailed solutions for digital products, but more often than not, Interaction Designers are only seen as interface creators.\n\nInteraction designers work in companies that look like these...\n\n\n
• #8: Internal - corps, non-profit, big or small\nAgencies - \nStartups - \n\nSo...\n\n
• #9: how does work gets done in the companies? Who can tell me the overall environment for interaction design work in the “real world”?\n\nProjects. We are part of project teams, and on those teams are many other people. And our goal on most of these teams is to create new, update or enhance the company’s or clients digital products so, websites, apps, etc. \n\nThe interaction designer’s role on this team is the\n
• #10: Solution person. It is our job to design the solution. Nobody else ever wants to admit this, but ultimately this is our responsibility.\n\nTo do that we usually follow this overall process.\n
• #11: This is the process that we have used for all time in developing websites, apps and other software. Whether you are doing waterfall or agile you are still doing this.\n\n Discovery - Understand Users, Understand Content, Understand Context\n Definition - Plan out and prioritize features\n Design (the solution) - Detailed Interface Design\n Develop - Code and Test\n Deploy\nUsually the discovery and definition are what happen in order to come up with a project. And so most of our work as interaction designers has ended up being here\n
• #12: The Design Phase. This is where interaction design happens, at least to most people. Now ignore the fact that ideally we should be involved in this entire process for this workshop. In here today we are going to work with the most often scenario. IxD is on a project (yes this is it’s own big problem that is tearing our profession to shreds)\n\nBut the biggest problem that we face as interaction designers, and the reason why we aren’t included in all these other steps is that we are seen as, and have come to be the owners of not the solution, but the interface. This, as we’ll talk about shortly, is bad news for us.\n\nIn order to demonstrate let’s first walk through how an interaction designer might get assigned work. Ideally (but often never) some group has done discovery (i.e. research, analysis, created personas, tasks, and prioritized scope). The company then\n\n1. needs something done so they put together a project team, and you get assigned to this project team. \n2. The team might be tasks with doing something like this...\n\n\n\n\n\n
• #13: So what happens is we get the work assignment. and we might be pulled into a project kick off meeting or get emails about it, we basically start getting a ton of information thrown at us...\n\nDoes this sound about right practitioners?\n\nSo as the interaction designer on a project what are you responsible for delivering? <ASK>\n\nBut here’s the thing to remember.\n\n\n
• #14: Who agrees with this? Who disagrees with this? Let’s discuss why this is so.\n \n So if the interface isn’t the solution than what is? It is a model of the solution in a way that users process through whatever medium they are using (cpu, phone, tablet)\n \n If the interface isn’t the solution then what do we do??\n\n
• #15: As framed by our philosophical thinker we do way more than just the interface. What is it that an Architect does besides just the blue prints?\n\n<Get down to synthesizing and strategizing the solution>\n\nSo our current state then is that we are in the Designing the solution phase, and often times we are pushed to jump directly into the interface, but don’t get nor take the time to synthesize and strategize the solutions. So our current state is missing one big and important thing...\n
• #16: We go from getting the project, to doing the interface, and this can cause us a great deal of issues. the main thing that happens when we jump to the interface is we leave this stuff out.\n
• #17: Don’t get consensus on the problem we are trying to solve\nDon’t know who specifically we are solving this problem for\nDon’t know what information, data, and content needs to be included in our interface\nDon’t know the user and business priority of that content, data and information needed to solve the problem\n
• #18: That we don’t actually solve the problem. And we don’t have footing, we have no rationale we have nothing. And this causes..\n
• #19: Without sitting down to synthesize and strategize the solution we end up with the cycle of revisions because we aren’t really basing our solution off of what the problem is.\n
• #20: We get less respect because we look like we have no idea what we’re doing\n
• #21: and we all go crazy!\n But maybe, just maybe if we all had a process in place that we could use to synthesize and strategize the solution before doing the interface we might be a lot better off. So our goal today is\n
• #22: Our goal today...\n\nAnd the outcomes of us doing that are\n
• #23: The outcome of implementing this process. \n Decrease the cycle of revisions\n
• #24: The outcome of implementing this process. \n Increase respect for IxD as a problem solver (not just the one that draws pictures)\n\n
• #25: The outcome of implementing this process. \n More responsibility and better projects\nSo let’s hop to it. Let’s learn a process for synthesizing and strategizing before the interface.\nKeep in mind this process will be given to you to take home with you.\n\nAlso this is formal... you are not likely to be able to formally to this in your job, but here are the questions we are going to learn how to answer and the things to do that we need to learn how to do before we go to the interface to avoid the steady decline of our profession.\n
• #26: \n
• #27: \n
• #28: \n
• #29: \n
• #30: \n
• #31: \n
• #32: \n
• #33: \n
• #34: Let’s take a 15 minute breather and get back here to start going through this process in detail. \n
• #35: Quick Check In\n - how is it going thus far? \n So far we’ve talked about\n How interaction designers are responsible for the solutions on projects, and how interfaces are not solutions. We see there is a lack of process around strategizing and synthesizing an actual solution\n The problems with not having a process\n Overview of the process\n Outcomes from that process\n That process for synthesizing and strategizing solutions before we do the interface looks like this.\n \n
• #36: So in part 2 we are going to investigating and practice these 3 things...\n
• #37: and how it’s going to work is I’ll introduce these topics for about 20 minutes then we’ll do an exercise to use this new knowledge in our groups for about 35 minutes then we’ll take time to present to the other groups and critique. \n\nSo let’s jump in...\n
• #38: Who am I working with? - Understanding my team\nWhat is it: Gaining understanding of all the skill sets on your team, how they can help you and and who on the project you need to deal with.\nWhen to use it: Before/during problem framing, figuring out who’s in the know.\nWhy to use it: To ensure you know your responsibilities and those of others in creating the solution. To ensure there are no gaps, and to be sure you are including the right people in your reviews and meetings so progress can be made.\n
• #39: Step 1 is to learn the base knowledge of how project teams are structured in your company, and the company of your client.\n\n1. Who here knows this? Can I get some examples of a basic project team structure? (have people give examples)\n a. here is are a few examples\n 1. One place I worked our project team was (tech lead - who was in charge of the devs and QA, Business lead - who ran requirements gathering sessions, Design lead - that was me. I was in charge or IA, Wireframes and Visual Design schedules and deliverables, Project manager - in charge of schedule, Program Manager, Sponsor)\n 2. Another company I worked at had (account manager, project manager, IA, Creative/ACD, Planner, Copywriter, Tech lead)\n b. You gain this understanding by showing up to the kick off, listening, looking, and answering questions.\n\nShow example project team structure\n
• #40: This is an example project team structure.\n
• #41: 2. We need to start to use any user research and/or empathetic skills outside of just design work. You can use those same observation skills to understand our environments. When you show up to the kick off observe who is in the room. Are there devs, business people?\n a. If you don’t know, ask questions!\n
• #42: 3. Know who you resources are, and use them to fill any gaps you have. The most important thing to note is who can you talk to. This is a nuanced skill, but an important one. Figure out who can answer your questions. And then... use those people to ask your questions and get your answers!\n Types of questions you may want to ask:\n Is this everyone who I’ll need to know to complete the project successfully?\n Who do I go to with questions about <design, schedule, requirements>?\n \n
• #43: 4. Do this not only for each and every project, but for your job as well! Who is on the design team, who is responsible for what.\n\n
• #44: Who can help me solve the problem - Knowing who’s in the know \n What is it: Taking the time to understand the business and who has a stake in the solution.\n When to do it: Before/During problem framing.\n Why do it: Gain an understanding of who has the power to do what, and who has a stake in which parts of the solution. \nThis is somewhat similar to knowing who is on your project team. However, the people in the know will be both a part of your team, and sometimes not. \n
• #45: When i say this, I’m talking about a switch in thinking...\n
• #46: Admitting you are a business person is hard. It means that we all have to buckle down and be real with ourselves. The fact is that we work for someone else, and even if we don’t the fact is we work to stay alive. To make a living, to feed our families and ourselves. Our company is a business that needs to stay in business and (hopefully) makes a product that is helpful. \n \nWhen I say admit you are a business person I mean admit that your design work is probably not going to save the world AND that it needs to help the business stay in business so YOU have to help the business people to do this. It’s a frame of mind switch from hating the business to realizing that helping the business is not only your job, but is also not selling out or going against our users. It is enabling us to do more for them.\n\n
• #47: 2. Understand who has the $$. Usually this is a product manager, maybe not if you are in an agency. Figure out Who is funding the project?\n
• #48: 3 is pretty much the same. The only differences are that our context is different. We aren’t just looking at our project team, but we are looking for anyone that has a stake in what we are doing. Program Manager, Product managers, Customer Service Manager - basically the people that everyone else is trying to make happy. We are also probably going to use more than we are going to get to know our resources here. \n
• #49: 3 and 4 are pretty much the same.The only differences are that our context is different. We aren’t just looking at our project team, but we are looking for anyone that has a stake in what we are doing. Program Manager, Product managers, Customer Service Manager - basically the people that everyone else is trying to make happy. We are also probably going to use more than we are going to get to know our resources here. \n\n
• #50: What is the Problem - Framing the problem\nWhat is it: The process of truly understanding the issue to be solved (and the business need behind it).\nWhen to use it: At the beginning of any project or design phase before we start designing.\nWhy to use it: So we can define the users to focus on, the business need to focus on, the technology involved, the data and content involved and the priority of that data and content. Ultimate goal is to get team buy in on the problem so we can focus our solution.\n
• #51: 1. Listen to the people around you talking and really hear them. Take absolutely nothing literally. This is a skill of awareness and concentration. If someone says “I like the search results for site abc.com because users are able to filter on all these different things.” then you can assume there is probably a problem finding specific items. General search may work just fine... but this is a cue that there is a different problem. Also if you are given requirements read through them and ask why.\n
• #52: 2. We have to know how has the information we need, as well as who has the most pull. These people are not only “in power” but have the most to lose and thus have the deepest tie to the success of your solution. They are usually executives and product managers, but with anything it can get political. So how do we know who’s in the know? \n a. get ahold of the org chart \n b. ask! - who owns the project... who is paying for it!\n c. watch people and how they react. If they are timid around another person, it probably means that person as more pull\n\n\n
• #53: You want to ask the right questions, and you want to ask them of the people in the know. Some examples of the questions to ask.\n\n How are we defining success?\n Are there numbers we are trying to reach?\n Will this solution have to lead to another?\n Are there other projects happening or planned that could influence this solution that I will have to take into account?\n What is the worst thing that can happen during this project? What does failure look like?\n Who out there has solved this problem and what makes their solution awesome?\n
• #54: 4. This is your time to take a step back and summarize what you’ve heard. Some of us will sketch it out, some of us might write it down, but this is the time where you take a stab at summarizing the real problem\n\n
• #55: Here is an example of a model you might show to your team to showcase the problem. \n\n
• #56: \n
• #57: \n
• #58: 5. And then you bring it back to your team and confirm it with those in the know. \n\n
• #59: So our problem for the day is that we are all interaction designers on a project team tasked to update the search. Our goals for this exercise are to figure out who’s on our team, who’s in the know, and what is the problem. \n\nYou have in front of you character cards which represent the people on your team for this project. These also represent the kickoff meeting for the project, and you are reading through who they are, what they are responsible for, and goals for the kick off meeting. \n\nUp here is the chart of who’s at the meeting. I will keep it up here for you to review throughout. \n\nThe way we are going to do that is read through our character cards which house the answers to the questions on the worksheet and provide us with the real problem.\nI’m then going to give you 25 minutes to answer all the questions, as a team, and model the problem. \n\nYou will then present you answers and the problem models to the group.\n\nThe goal of the problem models are to visualize the problem to the team so that the great project team and sponsors can confirm that “yes this is the problem we are trying to solve”\n\nExercise\n1. Read the character cards and any other materials, quietly no discussion - 10 minutes\n\nFor the next 25 minutes\n2. Now everyone at the table is playing the role of the interaction designer. I want you to work together to fill out the worksheet. All the answers to the questions in the worksheet are in the character cards!\n3. I also want you to create problem models to show the rest of us. \n\nExplain exactly what to have when you’re done\n\n\n
• #60: Answer the questions all together. then present problem models.\n\n1. Let’s review the answers to the worksheet \n2. Divide groups up into 2 large groups of 4 teams. \n3. In your groups each hang up your problem models and worksheets.\na. go through and present your answers and problem models and discuss and critique. \n\nWhat is the problem at company workshop??\n
• #61: \n
• #62: How was lunch?\n\nHow is everyone doing so far? Are we on path with what you expect to learn today?\n\nReady for the second half of our day?\n\nLet’s do a quick recap. We started off the day talking about\n How interaction designers are responsible for the solutions on projects, and how interfaces are not solutions. We see there is a lack of process around strategizing and synthesizing an actual solution\n The problems with not having a process\n Overview of the process\n Outcomes from that process\n That process for synthesizing and strategizing solutions before we do the interface looks like this.\n
• #63: In Part II of the workshop we just went over learning and practicing\n- Who am I working with \nKnowing the skillsets on your project team. To ensure you know your responsibilities and those of others in creating the solution. To ensure there are no gaps, and to be sure you are including the right people in your reviews and meetings so progress can be made.\n\n- Who can help me solve the problem\nTo Gain an understanding of who has the power to do what, and who has a stake in which parts of the solution. so that I can successful sell and solve the problem at hand. \n- Framing and modeling the problem\nSo we can define the users to focus on, the business need to focus on, the technology involved, the data and content involved and the priority of that data and content.\n\nWe also took the time in our exercise of redesigning search for Company Workshop and figured out who is on the team and modeled the real problem. We are going to build on all of this in Part III of the workshop by\n\n
• #64: Understanding who I am solving for on this project and what is the information/content that I’ll be working with. \n\nand how it’s going to work is I’ll introduce these topics for about 20 minutes then we’ll do an exercise to use this new knowledge in our groups for about 35 minutes then we’ll take time to present to the other groups and critique. \n\nSo let’s jump in...\n
• #65: So the next thing we have to do, now that we know our team, and our problem... and have signed off with the team is figure out our audience. In large scale strategy efforts or in big projects, We do this by going through and going research and determining who are set of user types are and modeling them into things like personas. Does anybody here understand what personas are?\n\nPersonas are basically models of user types. We have three for Company workshop. The important thing to remember is that they are models that we use to focus on the tasks and goals of these user types. On most projects you will probably not be “allowed” to take the time out to create personas from scratch. I have been on projects where this happens, and in fact it usually happens in the Discovery and Analysis phase. But we are in the Design the solution phase and that means we have to strategize and synthesize the solution. We can’t do that without knowing who we are designing the solution for. \n What is it: the process of focusing our attention on the users affected by our solution.\n When to use it: After problem framing, while gathering content/information to use, when getting ready to prioritize.\n Why to use it: To focus the solution on those that need it most.\nNow remember, we are working in a world where Discovery has already been done to some extent as has scoping. This is rare that we get detailed personas, but it’s easiest for our workshop to have them. Whether you have them or not you still need to determine who exactly you are designing for.\n\nLet’s walk through how to do it. Our first step in paring down personas is to...\n
• #66: We took the time to define the real problem. Who is effected by this problem. Some users are usually more effected then others. So use that knowledge of your problem model to determine this. \n\nWhat is our real problem?\n\nSo of our three personas, who is effected by solving this problem?\n\nIn our example, who is it? Could be anyone right? But think about a different project. What if we were redesign the team sneaker page... who might we gear that towards. Ok so for us it all three personas. \n\n
• #67: For our purposes we already have personas, but if not do not fear. Personas are best if based off real research, but are still valuable if created based on what the team knows. Tamara Adlin had a great virtual webinar on uie.com The power of ad hoc personas, where she takes you through how to do this with your teams. \n\nBut even if you can’t do that, you can verify with your team and yourself asking “what is it that people are trying to do here?”. In our examples of search they aren’t trying to search, they are trying to find something on a website. So ad hoc personas are a whole other workshop, but I wanted to raise this point since we most of the time won’t have personas. \n\nThis exercise though should help you to know what you are trying to do with them. \n\nOk so let’s review the tasks for our hardcore fan together. \n\nBring up persona and show... Let’s everyone take a moment and do that here.\n\n Now that we’ve read through this and started to absorb it, let’s move onto step 3.\n\n
• #68: Look at persona and do together. So bringing our persona back up, which are specific to our search project?\n\nGreat so let’s take our list and put it into a spreadsheet for now. However you best organize it. \n\nNow onto step 4\n
• #69: Notice how the tasks are structured. There aren’t specific solutions in them... they are from a user’s point of view, not a system’s point of view. \n\nSo now that we know who we are solving for, and we know what tasks they’ll do on our project design. We need to figure out what information we’ll have on the page. From here, it’s pretty clear that they will have a filter on this search, but what does in it? So in order to figure out these details, we move into figuring out our content.\n
• #70: What is it: The process of determining what type of content or information needs to be manipulated to solve the defined problem.\n When to use it: After problem framing and paring down personas, before modeling.\n Why to use it: To get a clear idea of what to include in the solution (and eventually the interface) in order to meet user and business needs (aka solve the problem).\n\n
• #71: This step is where you need to use your design skills. It’s not about where will it go on the page, it’s about what does the user want to do to here. What are their tasks. We want to try to keep our tasks high level so that we can break them down in a bit. \n
• #72: Tasks are really what is the user trying to do\nInformation requirements are what types of information/data/interactions does the user need to complete these tasks?\n\nWhat might these information needs look like for the hardcore fan?\n\n\n
• #73: Next you’ll want to prioritize this information from the user’s standpoint and the businesses standpoint. The user stuff you’ll know. The business stuff you will be “guessing” at, but since you have been listening and talking to your business team these are informed guesses. If you are unsure then we’ll just make a few versions to get feedback. \n\nThese are what you need to design for. But wait? How do we know that we have this right? Well we have to model our information. And we don’t want to put this in an interface at this time, because why?\n
• #74: What we’re going to do is take the remaining two personas and fill out the tasks list for each. Then we’re going to turn those lists into information requirements. \n\nExplain exactly what to have when you’re done\n\nStress that they should come up with more tasks than what the personas have. \n
• #75: Break up into two large groups of four teams. Review and refine lists, critique etc. The goal is to verify and add any tasks, we want a comprehensive list so that each team and model the right solution. So we’ll have two lists and we’ll review those two lists as a big group.\n\nGet together at the end and talk through with both teams\n
• #76: \n
• #77: Welcome back! So this is our final moment together... Part IV of the workshop. Let’s do another quick recap\n\nWe started off the day talking about\n How interaction designers are responsible for the solutions on projects, and how interfaces are not solutions. We see there is a lack of process around strategizing and synthesizing an actual solution\n The problems with not having a process\n Overview of the process\n Outcomes from that process\n That process for synthesizing and strategizing solutions before we do the interface looks like this.\n
• #78: In our last session we looked at \n\nWho am I solving for - \nto focus the solution on those that need it most.\n\nWhat is the information/content that I’m working with? - \nTo get a clear idea of what to include in the solution (and eventually the interface) in order to meet user and business needs (aka solve the problem).\n\nSo we’ve been synthesizing and strategizing the solution for our project to make search better for company workshop. And we now have information and content, users, problem.... we can start the interface right? Wrong... \n
• #79: In Part IV of the workshop we are going to focus on. This is going to allow us to present the solution in such a way that isn’t the interface but that represents user and business priorities. So when we do draw the interface we’ve already agreed on how to solve the problem. \n
• #80: What is it: Process of sketching the information relationships in order to get team feedback on priority. \nWhen to use it: After understanding who you are solving for and what information/content you are working with.\nWhy to use it: To have a visual model that will showcase content and information priorities in order to get the greater team on the same page.\n
• #81: Bring up information list\n\nNow this is where your priorities come into play. You have talked to the business/client, you know which of their user’s is the most important. Thus those user tasks in regards to search should probably have a higher priority in your solution. When we look at your sheets of information requirements, those for the hardcore fan are probably the most important right?\n\n
• #82: Using the priorities information you came up with, you want to model the solution. \n\nWe also will want to go look at the competition (finishline.com) that our business partners mentioned. Let’s take one of our top user’s tasks and see what we can do with it here. \n\n\nSo let’s go to an example that I did for this purpose. \n\n
• #83: Using the priorities information you came up with, you want to model the solution. \n\nWe also will want to go look at the competition (finishline.com) that our business partners mentioned. Let’s take one of our top user’s tasks and see what we can do with it here. \n\n\nSo let’s go to an example that I did for this purpose. \n\nHere are some other less formal examples of solution models\n\n\n
• #84: \n
• #85: \n
• #86: What is it: Using your knowledge to make the case for your expertise. (aka: selling your idea to the team)\nWhen to use it: When you have modeled the solution.\nWhy to use it: To bring the user voice to the conversation/solution..\n
• #87: This is important... this is really important. Why did you design these models the way you did? We’ve looked at users, we know what the need. We’ve interviewed the business, we know what they need? And we know interaction design and usability principles... that is our expertise. With those forces combined you should be fueled up and prepared to go. \n
• #88: And this is important. Take the time to prepare. Let’s look at our example model. Why is the filter the way it is? Anyone?\n\nKnow every single element on the page and why you put it there. \n\nBut keep in mind... don’t argue about it. Provide expertise and guidance. If a teammate says they want to remove an important feature say the filter say “ok that’s fine, but that will mean not filling any of these requirements from the user. Is that ok with the business?” and finally...\n
• #89: Sell it baby! What does this mean? It means have a passion for your solution. it is your thing! So now that you are ready, what is our final step?\n
• #90: This is about Understanding priorities\nWhat is it: Getting team consensus on priorities, using your models and knowledge.\nWhen to use it: After you know who’s in the know, after modeling, before interface design\nWhy to use it: To get team consensus on the solution.\n\n
• #91: Remember how we marked off who was in the know, who was on the team and why... well this is why. They need to be here. And once you get them all together. \n
• #92: Review the different models you’ve come up with and see which best matches their business and tech needs. \n\nSell is Baby! Sell this jam you are the expert. But don’t take criticism the wrong way, use it to make this better. \n
• #93: You can get this by being persistent but not pushing. You are looking to hear yes, move ahead. \n\nOnce you have sign off on these things, then wireframe, sketch, photoshop... whatever. But doing so before hand will only make this a painful and pointless solution. now let’s practice.\n
• #94: Using your information requirements list, model the solutions you have.\n\n1. Create models of your solutions - 15 minutes.\n\n2. Practice getting sign off\n- break off into two groups and each team sells and gets sign off\n- have a few teams sell and get sign off\n\n** SHOW EXAMPLE MODEL ON SCREEN\n\nExplain exactly what to have when you’re done\n\n
• #95: So let’s do a quick recap to bring it all to a close. We talked about interaction design today. How IxDs can be in many different companies but we are ultimately always responsible for the solution. \n
• #96: The solution, is not the interface however. We should not just be creating wireframes, there is so much more to our role. Specifically we need to be like the architect and synthesize and strategize the solution before modeling it in an interface. \n
• #97: We need to go through the process of getting these questions right. Examples of the type of outputs you’ll have are\nProblem models\nInformation requirements\nSolution models\n\n
• #98: By leading your team through the solution process and getting the right solutions for the right problem you become the advocate for IxD thus bringing better solutions and more respect for all. \n
• #99: \n