mattyunijourneybrief12 - Tumblr blog

mattyunijourneybrief12 · 4 years ago

Text

Week 4 Activities

Design Ethnography

Design ethnography is a method of research that allows us to get a deep understanding of people.

vimeo

Linkedin learning: UX Design: Creating Personas

Who are you developing for? How will they use your design? Building user personas can answer these important questions. In this course, Chris Nodder shows you how to create personas using information about the users most relevant to your business. He shows you how to gather and use data from interactions and site visits to define groups that represent a picture of your user types. These personas can help drive development and make sure your team is designing your product, application, or website with the same customer in mind, resulting in coherent, focused goals and an optimal user experience.

Hello, I'm Chris Nodder. Welcome to the third installment of the UX Design Techniques series. In this episode, we'll discuss creating personas. I'll show you how to use the data you've gathered from your site visits and from other customer interactions to build a picture of the users you care most about. Having this common understanding will make sure the whole team is designing for the same people, so the interface feels coherent and focused. Now it's time to dive in and create some initial descriptions of your target users, so let's get started.

Personas are imaginary, yet realistic and detailed descriptions of the users of your product. They provide a basis for design discussions by concentrating many pieces of user data into key focused, believable descriptions of your primary audience. Creating personas gives the team a shorthand way of describing who they're building things for.Rather than saying, the user, which could mean anyone. To focus on some set characteristics with specific attributes means that product development takes thosepersonas's needs into account. The whole team needs to buy into the concept of personas.The easiest way to ensure they agree on the key attributes is to get everyone involved in creating the personas to start with. Now, how can just a few fake people be sufficient for designing a whole product? As you'll see the personas you create are highly representative of your key users. Their value is in the focus they give you. Rather than trying to be all things to all people, this focus will mean you deliver a streamlined product with a consistent message. What's really interesting about persona-based design is that, although you're only designing for a couple of key individuals, the vast majority of your user base is likely to share the same needs, or at least be able to work with the same features. So by focusing clearly on the requirements of a small group of users, you actually build a better product for all your customers.

Personas are created from site visit data in order to focus future design and development efforts. They're essential for ideation, scenario creation, prototype development, and for recruiting the correct user types for prototype usability testing. You can create personas at any time during the development process, but the earlier you do it, the more benefit you'll get from the focus the personas provide. The best time to introduce personas is just after you've finished analyzing your site visit data when the site visits are still fresh in team members' minds. Hopefully, you already conducted site visits with people who you think are representative users or potential users of the product you'll be building.That means their attributes and behaviors are likely to be representative of the attitudes,skill level and background knowledge that you expect in your general user base, so you can use data from your site visits as one input to the personal creation process. As we described in the analyzing data course earlier in this series, part of your experience mapwas set aside for listing user attributes. Now you can revisit that information to help inform your persona creation.

Personas give everyone on the team a common vocabulary for describing the users you will design and develop for. As a result, decision making is easier and the resulting product is more focused. By common vocabulary I mean that team members can use the personas name as a kind of short hand to describe a set of attributes, desires, and behaviors. The attributes, desires, and behaviors are well enough defined that by using the personas name everyone in the conversation immediately knows how that persona might respond to the interface you're developing. In fact, it's a sign that your personas are successful when team members start using the personas names in their everyday conversations about the product. For instance, saying, "Yes, George would want it to behave like that," or, "No, Jesse wouldn't expect "to see that type of interaction here."Having clearly stated persona attributes also helps in decision making. You might be wondering how important each of a set of new potential features would be to your users.It's easy to take what you know about your personas and use that as a way of prioritizing the different features. If your personas are clearly defined, everyone on the team should be able to agree about which features will provide the most benefit for those personas, and so, which features you should give priority to. And building your product for a set of well defined personas means it will have a focus that would be lacking otherwise. That focus is important, because it makes sure the interface behaves consistently, uses common metaphors, doesn't jump between being aimed at novices and being aimed at experts, and doesn't include just in case features. You know the type of thing I mean, a menu option or other functionality that's put into the product just in case there's one user out there who might want it. Having a defined group of target users means that just in case features can be removed from the priority list, because they wouldn't be useful to your personas. That ability to streamline the product alone is worth the small investment in creating personas.Even if not every user matches your persona description, they will all appreciate the cleaner design that persona focused development allows you to create. Next, I'll explain how to create some simple initial assumption personas, which should be good enough to get you started on the development path.

If you asked everyone on the team to think of the color blue, and then showed each of them a selection of Pantone color swatches, how many of them do you think would choose the same swatch? It's the same thing when we ask the team to think about the user.Each of them has a different picture of who the user is. If you're lucky, it's the last customer they saw. If you're unlucky, it's more likely to be the generic "my mom." When you build software, that user description gets stretched in many directions. Sometimes, someone on the team suggests that the user is experienced. Sometimes, they aren't. Sometimes, they're older. Sometimes, they're just out of college. The result is a product that aims at different users at different points in the interaction. Real users aren't made of elastic. They find it hard to cope with our schizophrenic interfaces. Personas let the whole team get on the same page. By creating an explicit persona, you make the concept of "the user" concreterather than elastic. Even if the persona you created is slightly different from each real-end user, your customers will much prefer a consistent interface over an inconsistent one. Any focus is better than no focus when it comes to product design. Products that don't tell a clear story are harder to learn and harder to use. By building a product around key persona's needs, you give it that focus. In the next video, we'll talk about the easiest type of personas to make: assumption personas.

At this point in your design process, you might not have a large amount of data about your users, however, you can still build personas based on a combination of the data that you do have, and some assumptions that you make about your user base. The important thing, is to make the assumptions clear, and to talk them through with other team members, this helps you reality-check your assumptions, and then follow up with more data collecting activities, to flush out your assumptions later. The important thing, is to note which persona attributes are based on assumptions. Later on, when we recruit users for usability testing based on these persona descriptions, it will give us an opportunity to test our assumptions, and work out whether our personas need to be tweaked at all. This way, you always have a working model of your personas, and you make small course corrections over time, as you learn more about your users' needs. It's worth mentioning here that personas aren't the same thing as market segmentation. Market segmentation divides customers by the type of purchasing decisions they make. For instance, are they cost-conscious, or early adopters? Market segmentation forms groups using similarities based on statistical attributes, and it's primarily used to create product differentiation strategies,such as pricing, and features. It describes types of customers in aggregate format. In comparison, personas describe actual users and their behaviors, however fictional the individual really is. Personas are based on the tasks that people want to perform with the product, and they are used primarily for feature creation strategies, such as deciding what features fit with user needs. Market research data can still be really useful for persona creation, but personas are focused more on the creation phase, than the selling phase of product development. So, next, we'll look into more detail at the process of creating assumption personas.

The process of making personas is quite simple. It's best done as a team, because then every team member feels like they've contributed and so they can buy into the final personas. First, consider the users you observed during site visits. What attributes did they share? What qualities differentiated some from others? You might have these attributes listed in your experience map, or you can get all team members who attended the visit to individually write down the attributes on sticky notes. Now, group the attributes by bringing all the sticky notes together. Once you have some sensible clusters, name each group using a role described by its attributes. You'll probably create between five and 10 roles this way before people run out of energy. Now, you have to make each role personal and believable, taking each cluster of sticky notes in turn. Turn the attribute descriptions into a believable persona. On a large size index card, give the persona a name and an age. It often helps to give them a two to five word tagline. When I was working on Windows Vista,we had Abby the AOL Mom, Nicolas the Knowledge Worker and Ichiro the IT Pro, among others. See what your persona does in real life. Are they a student, a businessperson, retired? And what's their level of comfort with technology? How experienced are they in the topic your product will address? Justify each piece of information you add by showing how it's important to the design decisions you'll have to make later on. For instance, there may not be any point describing the car that the persona drives if you're building a document management system, but it could be every point if you're creating a forum for classic car enthusiasts. Think about the design implications of each of the pieces of information you've provided. For instance, saying that a persona is detail-oriented suggests that they may need to see certain characteristics in the product in order to be happy using it. What are those features? Now write down what their goals are when they're performing tasks with your product. Are they concerned about speed and efficiency, about accuracy, about looking good when they're using the product? What other needs do they have that might not be vocalized but which might factor into their product usage? Next, provide the context for how this persona would interact with your product. Is it through choice or because it's part of their work? Do they interact frequently or just occasionally? Alone or as part of a team? Is their interaction on a mobile device or on a PC? What are the things they need to be convinced by before they would be happy to use their product? In other words, what are their concerns? It's also good to add a couple of quotes that really sum up this persona's attitude. Normally, these will be really easy to find just by looking at the sticky notes on the experience map you already created. After you've done this for several of the clusters of attributes, you'll probably start seeing similarities between some roles such that you could merge them. Maybe some of the roles are feeling more important than others. If you can, narrow your list down to just two personas. Maybe with just one additional secondary persona. For instance, a call center support person within the organization who has to interface with the application in order to help customers. If you have a large product with a diverse user base, you might end up with more personas. However, for any one feature set,you need to define the top one or two personas that you care most about for that feature.Whittling down the number of personas is difficult, even at this early stage, because even with such a meager description, you're probably likely already becoming fond of some of the individuals that you've described. But you'll thank yourselves later for being ruthless now. It's much easier to keep the needs of two or three well-differentiated users straight in your head than to try and please a whole herd of ill-defined individuals. The results of this early streamlining will show up in a more focused product.

The first uses for your new personas will be in the user centered design techniques that follow this course, ideation, scenario creation, and paper protoyping. But personas don't stop there. As the team continues development work, they'll be making decisions about what interaction style users might prefer. Wherever the team needs to focus on who their users are, they should be referencing these personas rather than falling back into talking about the generic user, whoever that might be. Personas are really usefulfor streamlining the conversations you have as a team during design activities and feature prioritization discussions. They make it easier to remove the personal opinions of team members from the discussion. Instead of starting a sentence with I think, you can say our primary persona needs. Personas also serve many practical purposes. If you need to describe your target audience to anyone, you can list the top attributes of your personas.When you recruit for usability studies, you have a ready-made template for the attributesyou want your participants to match. The more you start adopting these personas, the more likely it is that you'll want to move beyond your initial thumbnail sketches and start gathering more data to backup the assumption personas you created. We'll discuss that process in the next chapter.

You may find that assumption personas are sufficient for your needs on a shorter development job. But if you're likely to be building software for the same users over a period of time having a set of database personas really helps to keep the team focused on who they're building for. This in turn, keeps the user interface focused and makes your users happy. By data based, I mean that every statement on your persona descriptions is backed up by data points and you have additional back up data points that cover other activities your persona may perform and interests they may have. The additional data backing up each of your persona statements, makes the personas much more believable.And also, much more defensible. If someone on the team questions where the customers really do behave a certain way, you'll be able to use your data driven personas to verify that you're heading in the right direction. Typically this is also the time when your personas graduate from being handwritten on index cards to being glossier, well designed posters that you can share with a wider audience. Just recruiting usability test participants to match the assumption personas will help verify your initial decisions. However, there's more data you can collect to build more stable, believable, and accurate persona descriptions.

To build data driven personas you obviously need sources of data that relate to your target audience. Some of those will come from within your organization and some will come from third-party research. We've covered field visits already in the course on analyzing user data. The rich information you get back from watching people work with your product in their own environment is invaluable. You can augment it with other sources of information that your company is probably already collecting. Market research is a core component of most company's business. It's important to know what the current state of the market is in order to adapt products accordingly. You can use this research data to help you flesh out your personas. Marketing segmentation is not the same thing as personas as we've already said, however, it's important to understand why the marketing group has chosen to target certain groups and to see how that data corresponds with your personas.Hopefully you collect metrics, or at least have log files for your product that you can query to get usage information and behavioral data. Help desk calls are a wonderful source of information about your personas' wants and needs as well as their current level of expertise. Spend some time listening in on calls and ask the help desk or support group for a list of the top 10 user issues. The sales team are typically a great source of information.They know how the product is being used and by whom. Sales teams typically have contact management systems where they store information about customers. Just be careful using this data, though. Apart from confidentiality issues, often the sales team deal with procurement people rather than with real end-users. You'll have to work out which pieces of data are relevant for the personas you're creating. Now, let's move on to third-party research sources that you can use. Plenty of research institutes sell and give away data.Think tanks, trade groups, and non-governmental organizations such as Pew, the International Monetary Fund, stats.org, Pollingreport.com, and Yougov.com all produceoriginal research and make it available for free. Even if you aren't interested in the main topic of a report, or think that the organization is trying to push a certain agenda, it may contain useful demographic or behavioral data that's relevant to your case. For instance, a report on broadband adoption might note that average data connection speed for certain segments of the population, one of whom is a good match with your persona. Then, there are research organizations who sell reports based on data they've collected. There are the bigger players like Forrester, Gartner, Gallup, comScore, Quantcast, and Neilsen ratings.Then, there are companies who work in the user experience space such as Nielsen Norman Group, UIE, and Human Factors International. You might not have the budget to pay for a full report but these organizations always tease with useful snippets. You can find those in blog postings and in press releases. Finally, there are government databases. Sometimes these aren't as easy to parse as you might like but they tend to contain some of the largest data samples. I'll just list a couple here. The US Census Bureau, the CIA World Factbook,Centers for Disease Control VitalStats, FedStats.gov, and Data.un.org. The examples I've given here are mainly US centric but, hopefully, you'll see the opportunities here and you'll be able to search out some of those data sources in other countries if you need a more local flavor for your personas. The best way to use these sources is to approach them with a question in mind. Otherwise, you can spend hours browsing without gaining any real insight. So, use the data you gather to back up your observations from the field. You might have a question like, we saw two users have problems with passwords. How many failures do we get each month? That's the kind of answer you'd expect to find in your site metrics or server log files or maybe from support staff. Or, you might want to know how likely it is that one of your personas would use an online backup system. So you want to know what bandwidth that type of persona has on average. Industry reports and NGO whitepapers will be a good starting point to answer this question. Remember that you're trying to find data that will verify or augment your initial assumption persona descriptions. Of course, once you've found it, you need a way to catalog it. The initial persona description scrolled on an index card isn't going to be sufficient anymore. In the next video, we talk about how to maintain a data file for each of your personas.

Storing all the information you find about your target Persona's needn't be difficult. You can keep it all in a single document, adding to it over time as you gather more data. Split the document into sections, such as Attributes, Goals, Scenarios of use, and Background information. Add new data to it as you find it. And include references to the source of each piece of information, whether it's site visits, or usability test results, URL's to online articles, or links to other company research documents. Here's the really important point about persona data files. Don't share them with anyone. Instead, share the information they contain, and do that in easily consumable chunks, such as posters or summary documents. To clarify what I mean by this, I will use an analogy that Jared Spool from UIE, adopted awhile back. There's a big difference between going on vacation, and seeing someone's vacation photos. You get an idea of the vacation from the photos, but you don't really experience it. So printing off the document as a record of your persona, is a bit like showing someone the vacation photos. It may say that looks nice, but they don't necessarily internalize anything. Instead of sharing the document, share your insights. Use the research you do to back up statements you make, or to clarify statements other team members make. Mine the research for new insights and product solutions. By continually doing new research, you keep the personas fresh, up to date, and most importantly, believable. You replace your initial assumptions with real data. And as a result, you can be more confident in the product decisions you make. The persona data file is just the storage medium for your insights and ongoing research. I've only given you a working overview of data-based personas here. John Pruitt and Tamara Adlin describe how to create assumption and longer term data-based personas in their book, The Essential Persona Lifecycle. This book is well worth reading, if you want to get more detail on the process of creating and maintaining personas over time.

How can you possibly do user-centered design without knowing who your user is? A persona description gives your team a common understanding of who they're building for, what that individual's goals are, and what types of interaction they'll be happy to work with. Just saying, "the user," is so vague that different team members can easily go in different design directions. That lack of focus really shows in the products you ship.Instead, creating personas lets you share the basic information about who the product is for. This information is the foundation of a focused, clear, interface that really meets users' expectations. As we've mentioned before, this course is one in a series on user-centered design. Subsequent courses in the series will all make the assumption that you've created personas and will personas as a tool during the development process. This course has shown you the steps necessary to create assumption personas. Some options for collecting additional information to make your personas data-driven and the benefits of having personas as you move forward with user-centered design. Use your personas every time you describe your users. If you do this well, the persona names will become shorthand on the team for a shared knowledge about a set of attributes. The next courses in this serieswill build upon your personas. When you ideate to create a wide range of design ideas,you'll do it with your personas in mind. When you write scenarios, you'll be writing them for a specific persona. When you create design sketches and prototypes, you'll be building them for a specific persona. When you run user studies, you'll recruit participants who meet your persona description. These tasks all require a good understanding of who you intend to build for. You can approach these activities with more confidence once you have a suitable assumption persona. Personas put the user in user-centered design.

Linkedin learning: UX Design: Creating Scenarios and Storyboards

Scenarios and storyboards provide an understanding of the design viability by covering details on each interaction. When using a particular design such as an app, a user will be in a scenario when using it. It is our job as the designer to ensure these scenarios have been looked at, analysed and designed accordingly to ensure the user faces no problems. The job of a storyboard is to ensure we know how we can make the users happy.

If a designer were to rush to the creating part straight from ideation, they would likely miss some important nuances. In the design stages, creating scenarios and storyboards happens straight after the ideation.

In order to get the information you need to conduct ideation exercises, you need to:

Observe users

Create an experience map to extract pain points, goals, and personas

With these, you can make design charrettes, which give you a set of potential design concepts to work from. To make sure that these ideas work in the real world, scenarios and storyboards help to move towards creating the prototype.

In the ideation phase, it is important to focus on reality and how the users will interact with the product. It is also important to be aware of problems that halt the flow of these scenarios.

When working in a team, it is important to have a level of agreement and everyones goals come together. The different team members involved will bring the motivation from their own backgrounds to the table, so the end result will incorporate those elements into the team scenarios.

If this happens, there will be less chance of disagreements and delays to the development cycle.

There are many benefits of scenarios and storyboards, as you can see below:

One benefit that stands out to me is that they are incredibly visual, which helps massively in depicting the experience you want to produce. They are also incredibly simple to understand and it takes a minimal amount of time to create them (they don’t need to be detailed drawings etc).

Storyboards describe a combination of:

User needs

Design concepts

Input conditions

Expected outputs

Creating scenarios and storyboards are essential as they prevent you to do rework further down the line in the project.

One way I like to look at it is this:

Think of a design project like building a brick wall. It is essential to place the bricks on the bottom in order to place them at the top. Without the bricks at the bottom, attempting to place the bricks at the top will always result in them falling to the ground.

Before the designer creates scenarios, it is imperative that they know who they’re building for, what the user issues are, and what potential solutions they could use to solve them.

Choose one or more of the user activity areas from your experience map to write a scenario around. Although the experience map describes the current situation, rather than your ideal situation, you'll still need to either accommodate or replace each of the user's current activities in order for your new design to be successful. Grab a stack of sticky notes and start writing out each step the user must take to reach their desired outcome. One per sticky note. I found this works best by just telling each other story fragments of what the persona might do to reach their goal. And then writing each step on a sticky note. As you go along, you'll probably find the need to embellish earlier steps with additional information.Or to add extra steps, that's were the sticky notes come in handy. It's easy to re-arrange or add notes, to add steps you forgot. You'll end up with a sequence of sticky notes, each describing a step in the interaction. Sometimes, for easier tasks this might only be five or six sticky notes. Other times, for longer and more complex interactions, you might end up with a couple of sheets of paper each containing multiple sticky notes. Now if you had several pairs of people working on the same scenario, it's time to compare the stories you each created. Go around the room taking it in turns to read out your scenario. And let other team members ask questions about how the persona might react in certain situations. After you've been around the room, take the time to combine the best elements from each groups scenario into one overall scenario. This combined scenario will become the point of reference for creating a storyboard and subsequently your actual interface. So take the time to make sure it covers all the points you care about. You'll need to repeat this scenario creation process for each part of the interaction for which you're designing a solution. You'll know your done when your scenarios cover all of the user tasks you need to support and meet all of the goals you set.

Here are a couple of tips to help make your scenario creation exercises go smoothly. The first is to reiterate the need to do this exercise in pairs. Because everyone must work with another person, they have to say out loud what the user's actions should be. Having to verbally describe the stories to someone else ensures that you write it in a way that other people will understand. When you come back to this work in a week or a month, it still needs to make sense. By writing it coherently first time, it's harder for other people to misinterpret what you mean later on. My next tip is don't describe interfaces, instead describe interactions. By this, I mean that when your scenario talks about your persona's interaction with the product, describe what they put in and what they'll get out, rather than the actual method they use to achieve their goal, so rather than saying Fred uses a dropdown menu selector in a modal window to choose the correct option and then taps the Done button, just say Fred chooses the correct option and then moves on. It's easy to build interfaces later, so don't get tied down into a specific design approach yet. The interface should be determined by the interaction,rather than the interaction being determined by the interface. Finally, if you really want to make sure that you've created a good scenario, try acting it out. You can even have someone on the team play the role of the computer if that helps. When you act it out, does your scenario feel realistic? Does it seem achievable? Good scenarios should progress naturally and the act of walking through it verballyhelps you to find any disconnects.

I often find it helpful to turn scenarios into visual storyboards. Storyboards were first used to help plan out cartoon animations, then later, to do the same thing for film.Storyboards help movie directors and producers to set out the scope of the interaction and make sure that the story hangs together in a believable way. That is all just as relevant in user interface design. Storyboard allows us to bring elements from the film world to UI design, the visual element allows for depiction of emotion and of action, both things that are hard to show in words alone. Visuals also allow the storyboard to pull our attention to a specific element of the UI, or interaction by drawing a zoomed in image, or to make us thinkabout the bigger picture, by drawing something from a wider perspective. It's not essential, but many people react better to seeing things in a visual medium, than with words alone.Although storyboards still don't show the actual user interface, they show the user's progression through the interaction. This can help to firm up the design, remove unnecessary steps, and demonstrate where additional work is required. Storyboards are also really useful for demoing to executives who can't, or at least don't take the time to read. Best of all, most of the information you need to create your storyboards already exists in your scenarios. Although it's not a one on one mapping from the scenario to the storyboard, the same elements will need to be shown in both. If you first created a good scenario, it will be much easier to move on to building your storyboard.

Storyboarding is one activity that's normally undertaken by just one or two individuals using the scenario input that was created by the whole team. The idea is to take the scenario text and create a visualization of each scene, showing how the users interact with the software and with their surroundings. You'll probably find an almost one-to-one relationship between the sticky notes from your scenario and the panels in your storyboard.But that isn't always the case, because often, a storyboard visual can cover several scenario steps. I find that it helps to establish a couple of shots that you'll repeat throughout the storyboard. For instance, the general scene, a closeup of the device, a depiction of the user interaction, an image that demonstrates the user's reaction to the interaction. Now, just use the most suitable of these shots for each scenario sticky and fill in the details that differentiate this panel of the storyboard from all the others. Like we already mentioned, storyboarding originated in the animation and movie industry. Directors would use storyboarding to test out different camera angles in order to help tell their story. You can use similar film-like camera angles as you draw your storyboards. For instance, you can establish the scene with a wide-angle view or use a close-up of the user's face to show an emotion. Or, you could draw a closeup of part of the interface to show a specific interaction. Sketch each panel on its own piece of paper. I find that three inch by five inch index cards are an ideal size, and then place them in order on a backing sheet of paper with room below each for a written description. The written description may be the same wording as the scenario, but it may be possible to edit that wording down now that there's an image that describes most of the action. Remember that your storyboard may still change as you progress through the sticky notes from the scenario, so don't glue any of the panels down until you're sure about the order. When you're done, review the storyboard with the team. Take their comments into consideration. Everyone on the immediate team needs to understand the storyboard in order for it to be a suitable artefact as you move through the process and to use it to create the actual interface.

Here are some tips for creating storyboards, to make them truly useful as you continue through the user-centered design process. The best advice I can give you is to display only the images that move the story forward. By that, I mean create panels for your storyboard if there's a change of scene, of if you need to show a specific piece of information, but don't worry about showing the interim states. You want to move the story forward, rather than getting bogged down in minute details. The only time you really need to show the interim states is if you think that there's an essential element of the interaction, or a system change, that you need to denote to help people who will be using the storyboards later to translate them into actual interfaces. If that isn't the case, or if the interaction will follow a very standard process, don't bother showing those interim steps.You may have noticed how the user interfaces in movies tend to be oversimplified, they often just show a couple of text entry boxes on the screen where in reality, there will bemultiple form fields displayed. Or they display big red flashing access denied text when the hacker tries to get into the system, whereas in reality, the response would be muted and would not obscure the rest of the screen. Now, although you'd never build it that way,remember that you aren't designing user interface in these storyboards, instead, you're trying to express the tone of the interaction, so it's fine to just highlight certain parts of the interaction that are essential for telling the story, just like in those cheesy movies. Here, I'm showing the only parts of the product information page that are essential for the story, even though in reality, there might be other items such as a product description, specifications,customer reviews, and so on. This is one part of the user-centered design process that sometimes lends itself to being done on a computer. Because you'll be reusing template images, it might make sense to use a presentation tool like Powerpoint or Keynote to build the story panels. In fact, there are already public domain templates to help you do this. For instance, the ones created by Martin Hardy at designcomics.org, but there's no requirement to go digital, and I still like the very immediate and immersive feel of a hand-drawn storyboard. Ultimately, it's up to you and your comfort level with creating the storyboard images.

http://designcomics.org

Personally, I think I will go with sketching the storyboards, as it enables me to be more free with my designs, and they can be completed and adjusted quickly.

Scenarios help to keep you honest. Some designs look great, but are unachievable. As the saying goes, the devil is in the details. What scenarios do is help you to work out some of those details before you commit to building a product around a single sketch of a UI that may or may not work. Storyboards help you communicate. Though they aren't essential for moving forward, having a visual depiction of your scenarios could help with getting buy-in from other team members or management, and can help identify issuesthat you wouldn't see in text alone. Early feedback is much cheaper than writing the wrong code. Writing things down as scenarios, then visualizing them with storyboards, lets you find issues before you've invested in interface development. It means you build the right thing first time, saving the time and expense of code rework. Next, you're going to be creating paper prototypes of the interface you're working towards. Your scenarios and storyboards should give you everything you need to make a paper prototype. This lets you test your ideas with real users before starting development work at all. We'll cover the transition from scenarios and storyboards into actual interface components in the next installment of this series.

0 notes