Just UX it up

1. JUST UX IT UP “ Lean UX is dead. Long live lean UX Greg Laugero ” MAY 31ST, 2012 KHAL WEIR AGILE UX ITALIA PAOLO CATTANEO
2. KHAL WEIR UX designer, novice longboarder and taco enthusiast. blog.khalweir.co.uk - @khalweir PAOLO CATTANEO Italian living in London. UX designer. Epicurean. Headbanger. @uxitup
3. WHY ARE WE HERE ?
4. WHY ARE YOU HERE ?
5. WHEN WATERFALL RULED Requirements Design Build Test
6. “ The only constant is change, continuing change, inevitable change, that is the ” dominant factor in society today. Isaac Asimov
7. DOESN’T WORK ANYMORE
8. “ Service design is the application of established design process and skills ” to the development of services. Stefan Moritz
9. GET LEAN BITCHES
10. “ Our highest priority is to satisfy the customer through early and continuous ” delivery of valuable software. 1st Agile principle
11. “ The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere. All successful startup processes should be ” geared to accelerate that feedback loop. 5th Lean startup principle
12. DESIGN & BUSINESSES FINALLY ALIGN
13. AGILE IS NOT A PROCESS IS A MINDSET
14. FUCK THE PURISTS WE NEED A SPRINT ZERO
15. “ The best is the enemy of the good. Voltaire ”
16. LEAN DISCOVERY Shared vision Use Cases Diaries Business Model Personas Mental Models Content Strategy Card Sorting Scenarios Competitor Insights Task Analysis Field Research
17. BEFORE YOU DESIGN SOMETHING YOU SHOULD KNOW WHY YOU ARE DESIGNING IT
18. FUCK REQUIREMENTS RECOGNIZE HYPOTHESES & VALIDATE THEM
19. REQUIREMENT Create a mousealator (wireless mouse with built in calculator) so people can do sums at their computer HYPOTHESES We believe that people like Alice have a need for a device that makes it easier to do sums while in front of the computer
20. REPLACE REQUIREMENTS WITH HYPOTHESES ✞ Hypotheses are answers expressed as if they are questions. ✞ In order for something to be an hypotheses it has to be testable.
21. REDUCE RISK, INVENTORY & WASTE I like No one this clicked Make a design Discover it 3 Months decision wasn’t right 3 Hours
22. OLD WAY VS. NEW WAY Risk Old way New way Time
23. PROBLEM STATEMENT We believe the people like (customer type) have a need for (or problems doing) (need, action, behavior ) TEST We will know we have succeeded when (quantitative or measurable outcome ) or (qualitative or observable outcome ) (business KPI) Which will contribute to
24. PRODUCT PERSONALITY
25. “ Voice stays constant, but tone varies by content type, context and message. Kate Kiefer ”
26. ASSUMPTION BASED PERSONAS
27. USE AN EMPIRICAL APPROACH CREATE ASSUMPTION BASED PERSONAS & VALIDATE THEM
28. emphaty map process
29. “ Work should begin with the hunt of value, ” and not until value has been validated.
30. FIELD RESEARCH GET OUT OF THE FUCKING OFFICE
31. “ While techniques, such as focus groups, usability tests, and surveys, can lead to valuable insights, the most powerful tool in the toolbox is the 'ﬁeld study'. Field studies get the team immersed in the environment of their users and allow them to observe critical details for which there is no other ” way of discovering. Jared Spool
32. AFFINITY STORMING
33. MEETINGS DON’T WORK ...AND THEY STINK
34. THE TOOLS post-its, sharpies, cookies & stopwatch
35. LOTS OF COOKIES CONFISCATE PHONES ...AND PRINT SHIT OUT
36. DESIGN STUDIO SKETCH UP, BITCHES
37. CREATE PITCH CRITIQUE
38. CROSS FUNCTIONAL TEAMS EACH MEMBER BRINGS A UNIQUE PROSPECTIVE OF THE CUSTOMER AND THE MARKET
39. THE TOOLS paper, sharpies, personas & stopwatch
40. CREATION PROCESS CREATE 6 TO 8 SKETCHES IN 8 MINUTES
41. THE DIRTY SECRET OF DESIGN
42. PITCHING PROCESS ✞ Which part of the scenario have you tried to design for? ✞ Which user’s goals have you tried to facilitate? ✞ How your design address your goals?
43. CRITIQUE PROCESS ✞ Come up with 2 to 3 ways the design solve the problem ✞ Come up with 2 to 3 ways the design could be improved
44. DESIGN IS A SLOW BOAT WITH PSDS WHAT CAN YOU DO TO IMPROVE THE VISUAL DESIGN PROCESS
45. REDESIGN SUCKS ...AND IT’S DANGEROUS
46. INCREMENTAL DEVELOPMENT & ASSETS MANAGEMENT
47. IDENTIFY ELEMENTS & MODULES THAT YOU WANT TO EVOLVE OVERTIME GLOBALLY
48. ELEMENTS An element is a solution to a recurring design problem. They are icons, buttons...etc, that have commonly accepted behaviors that make up an universally understood lenguage for software
49. MODULES A module i a chunk of a page design. Is a logical group of content and functions into a meaningful building block used in the interface design of a site
50. CHECK, MEASURE, LEARN Analytics User testing Diaries Surveys Task analysis Gap analysis
51. ITERATE MOTHER FUCKER
52. TAKEAWAYS ✞ Design + product management + development = 1 team ✞ Externalize! ✞ Goal driven & outcome focused ✞ Repeatable & routinized ✞ Flow: think > make > check ✞ Focus on solving the right problem ✞ Generate many options ✞ Decide quickly what to pursue & hold decision lightly ✞ Recognize hypotheses & validate them ✞ Research with users is the best source of information

Hinweis der Redaktion

\n
Hi, I'm Khal. I'm from a little town near Newcastle, which is why this talk is in English. I've been making stuff on the web for over 10 years now, mostly as a developer but more recently as a UX designer.\n\nHi I'm Paolo. I'm an interaction designer and i've been doing this for a bit more than 8 years. I started my career in Milan then I moved to New york and now I&#x2019;m based in London where we work for a company called dotdigitalgroup which produces SaaS software for marketers \n
So some of you might worder why we are here, why we flew 1000 miles to come to florence and talk to you\n\nPaolo miss home\nKhal just came for the food\nShare our experience with uxers in the same situation as us\ndouchebaggery\n\n
that&#x2019;s great! is good tyo have such a diverse audience as we think it will take all of us to make this shift\n\nWhat we&#x2019;ll be talking about today is the need to move from the classic waterfall approach towards a lean, agile one.\n\nWe&#x2019;ll explain how you can still keep the design practices we are used to and adapt them so they are more flexible, collaborative and faster.\n
But before start talking about agile let's have a look at how waterfall works.\nthis diagram shows the traditional way of building software. each dept. works in insolation and communicates only via documentation\n\nWaterfall was designed to fit the way businesses are structured.\nIt has a linear structure that enforce silos and it allows you only to move forward and never look back until the end of the process. When you finally look bask and test what you have done, it&#x2019;s too late too go back and fix things.\n\nThis suited us , we liked it\nIt was a safe place to be\n\nwe were mysterious superheros, handed requirements and given time to create beautiful pixels which we delivered with great fanfare. \n\nWe have never had to show our guts\nbest of all, we were so detached from the end product which sometimes came months later, we never got blamed for failures. the blame fell closer to those towards the end of the process.\nthe developers ran out of time, our beautiful pixels weren&#x2019;t realistic or even possible our design was only passed on the requirements we were given which were usually incomplete, dated and rarely based on real user needs. \n
Bu, in the last 5 years or so, things have changed. \n\nsoftware stopped coming in boxes and moved from the desktop to the web.\n\nAnd this had 2 major consequences in what we are doing\n\n\n\n\n\n\n
the move to the web altered users expectations and perception of what software could and should be. All the sudden we weren't releasing new versions of a software once a year.\n\nthe impact of traditional competitive advantages (such as price, usability, first to market, features) has diminished. the differentiator now is the human factor \n\nthe human factor is the reason I take a 45 minute journey across London to buy records rather than buy record from the nearby chain store. The staff in the local independent store love music, they&#x2019;ll take the time to get to know you and your tastes and make recommendations. they&#x2019;ll hold stock for you and let you listen before you buy. in short they care about customers and in doing so create a richer more fulfilling experience that is worth the extra journey time and actually makes me spend more money despite them being a little pricer than the chain store.\n\n\n\n\n\n\n
There is another thing, the systems we designs are getting exponentially more complex, too complex for only one person to deal with. We need new ways to deal with problems, we need tools that enable collaboration and communication.\n\nlike it or not, the application you are working on is not the only way your customer interacts with your company. theres a marketing website, theres support staff, there sales teams and social media. \neach of these is a touch point with the user and an area us designers should be interested in.\nwe are no longer designing products, we are designing services. \n\nto do this our job role must change so we become facilitators.\nto do this, we demystify design and we need to let people into our boxes and also get into their boxes.\n
waterfall doesn&#x2019;t let you go into other people&#x2019;s boxes. so we needed a new approach\n\nwe need to work in lean agile teams.\n\nlean and agile are terms that get used a lot, so lets take a minute to figure out what we actually mean by them\n
\n
\n
Agile principle and lean startup principle are the same thing, they both speak about bringing value to the user.\nAnd this is great for designers because for the first time we share the same goals as developers and business owners.\n\nDesigners fits in this environment because devs and business people often struggle to find effective ways to deliver the values that their principles are talking about.\nExample - devs often struggle to define done, they focus to much on the process, and they measure their success based on the amount working software they are able to deliver in a given amount of time and not on the value that the software brings to customers.\n\nOn the other end you have business people embracing lean startup philosophy knowing very little about how to get valuable insights from their customers in an effective way. this lead them to ask leading questions to their customers and gaining the wrong information.\n\nAs designers we can bring to the table all sort of tools to help them achieving those goals.\nAnd to do that we only need to adapt the tools we've been using for years so they can fit in the way these people work\n\n\n\n\n\n\n
Agile and Lean should be treated as philosophies not methodologies\nyou don&#x2019;t buy a book and decide to &#x2018;do&#x2019; Agile. doing Scrums and regular deploys doesn&#x2019;t mean you are working Agile. \n\nduring the sprint the workflow of UX practices are still based on the old model of practitioners > deliverables, with silos and hand off.\n\nyou can and should make a few tweaks and combine the core principles to create a process that suits you\n
Sprint 0 is like the discovery phase in a waterfall approach ,Sprint zero is not only for start ups, deepening on the project you can have sprint zero at any time.\n\nDuring this phase is important that you start finding an answer for some key questions:\nwhy are you doing this\nwho are you doing it for\nWhat problems does it solve\nWhat goals are helping to achieve \nwhat needs does it fulfill \nHow will you measure success\nwhat is the value that delivers both to business and customers\n
Don&#x2019;t try to get all the answers in one go, do what&#x2019;s enough to let you start the project.\nRemember that in lean environment research is ongoing and this won&#x2019;t be your only occasion to speak to customers before the user testing scheduled 2 weeks from beta launch, development and research will be done in parallel once the production has stardet\nDo just enough to get you going, as you&#x2019;ll see in minutes that often assumptions are enuogh.\n
These are some of the tools you could use during a sprint zero, today we&#x2019;ll talk about .....\n\n
Let's start from how to create a shared vision.\nFirst of all when we talk about shared vision we are doing it in very broad terms.\n\nWe believe that creating a shared vision is important because before designing something you and your team should know why you are designing it.\n\nA vision can have different levels of granularity.\nYou can have a shared vision on a product level or you can have a shared vision on a feature level.\n\nIt is important that you have one before start building a New product, but they are also important before imlpementing a New set of features in your excisting product.\n
\n\n\n\n\n\n\n\n\n\n\n
working in waterfall we were given requirements. clients and stakeholders love giving requirements. project managers and developers love them too because they are concrete.\n\nthe problem is : requirements \n\nrequirement are often are expressed as the only answer to a problem and take thinking out of the design and product teams. \n\nAnd if you take the thinking out of the product team you'll end up with a process like this\n\na business owner presents a list of requirements > the team doesn&#x2019;t get any visibility on users and market needs > the team does the implementing > After a couple of weeks you take a look at some metrics nothing has changed or things got worse.\n\nthis happens because Business owners have a distorted vision of of who users are, what their needs are, what design is. they often think that design is a pretty layer that sits on top of their products; designers are often asked to spend all their energy producing beautiful pixels and to get them right the first time. \n\nBusinesses overlook design, how good designers are at understanding people, their needs and goals.\n\n\n
\n
requirements have no place in a lean environment where the aim is validated learning.\n\nIt is important that those goals be testable, how will we measure success?\n\na hypotheses is waiting to be proven or disproven is in its nature. a requirement is done when a feature or product is built, an hypothesis is done when it has been proven to be true or not.\n\nBy asking good questions you enable learning encourage exploration, allow teams to have a shared knowledge of the problem and this knowledge drives them towards well defined goals\n\nwhy learning is so important?\n\n\n\n
Well one of the most important lean principle (lean manufacturing) is reduce inventory risk and waste.\nNow every design decision that we make an hypotheses and the market is going to test it for you. whether you like it or not this is how it will always work. \n\nthe real problem is time between making a design decision and discovering whether is right or wrong. we want to tighten this feedback loop, reducing the time between a deploy and learnings\n
The tighter feedback loop reduces risk - lets compare to the old way\n\nYou can take months and months to develop a product or you can reduce the time to go through that process \nand if you repeat the process over and over again you take the risk out of the project\n\nif you can you win!\n
Hypothesis can be created both at the beginning of a project or at the beginning of a sprint before implementing a set of features.\n\nA hypotheses consists of a problem statement and test\n\nThis is a template we usually use this as we are working on ongoing projects. but there are a few different versions, if you are working on brand new project then we recommend you using a variation of the elevator pitch\n\nGet people from different departments together and ask them to collaboratively fill the blanks and write the answers on sticky notes\nstick the notes under each questions, use dot voting to prioritize ideas.\nthen ask the participants to create a project vision each.\nOnce everybody has completed the exercise let them discuss and comparing what they have done until they have reached a strong direction among the group\n\nOnce you have created the hypotheses you then need to prioritize them and start validating. Start the validation process from the riskiest ones.\n\n\n\n\n
so you have a rough idea of who the product is for and a vision for what it will be. but who are you? How do you want your product to be perceived?\n\nyour product needs a personality. what characteristics define your product? Personify your product if it helps, if your product was a human who should it remind you of - use a well known TV or movie character or colleague. \n
What would Jack Bauer say if you weren't able to send a campaign due to insufficient credits?\n\nyou define a personality through look and feel and your product's 'voice'.\n\nyou speak to your customer through your product - every message, error and warning is actually a conversation. only it's a one way conversation. we want to design for emotions, both to trigger positive ones and XXX negative ones. if your customer feels nothing, they will forget you.\n\n
earlier this year we added a little message when you log out of any of our products. We rotate through a few messages and change them for seasonal occasions.\n\nThe afternoon we launched we spotted this tweet\n\n
Yay! We triggered an emotion and social stuff happened.\n\n(dirty secret, we added that message to hide a delay the new logout system caused - but instead of berating the developers or leaving a weird moment in the app we saw an opportunity to engage)\n\nhttps://twitter.com/#!/carlyyes/status/155072962469429249\n
MailChimp do a really great job with their copy, checkout their excellent voiceandtone.com - a website that acts as a styleguide for copy.\n\nThats a quote by Kate Kiefer's ConFab talk earlier this month. She is a copy writer at MailChimp.\n\nyour copy should be humanistic, appropriate for the target audience and situation. Working with our technical writer and marketing person I created a document that outlined our product's personality and included a tool which aids in writing copy.\n
We defined 4 characteristics we felt our app should have. They are opposites and when set to axis like this we can use it to determine the tone we should use in a given situation. \n\nYay, somebody completed your survey - thing and thing\nSorry, something went wrong and we can't save right now. Thing - thing.\n\nImagine how the user is feeling or how you'd like the user to feel at the moment. \n\nthis shouldn't be restricted to just in-app copy, every touchpoint with the customer should use the same personality. every tweet, blog post, hold message. \n\nthe visual and iteration design will be informed by this document too. Colour schemes, rounded fucking corners animations and gimmicks are all part of your personality/ perception strategy. Are you cutesy, serious and business like or wacky? \n
Why assumption personas before the development?\nIn an agile environment we need to move away from the old model of persona&#x2019;s creation.\nCompanies used to pay thousands of pounds outsourcing the creation of personas&#x2019; before even starting a project. But today the process of interviewing a lot of people and analyzing the data all in one go, is too time consuming, not needed and to risky.\nWe live time of extreme uncertainty and what you have find out today might not be true tomorrow. In an agile environment you need to constantly validating your decision with the people that will use your product.\n\nSo at the beginning of a project you need to do just enough to get you going. to start an agile project assumption personas are enough.\n\n
\n\nBut please don&#x2019;t get us wrong, we are not advocating that you shouldn&#x2019;t create data driven personas. Creating personas based on hypotheses should be seen as the first step towards a more data drive approach, at this stage you are basically creating assumptions on who your users are. The next step will be to get out of The office and find out whether your hypotheses are true of not\n\nAnother benefit of creating assumption based personas is is that they will create a shared vision on who your organization think your users are. this vision is likely to be very different from each department and this is a good thing especially if you work in an environment where design research is an hard sell. highlighting discrepancies in your organizations will make it easier for you to get permission to get out of the office an talk to users.\n\nThe only risk with assumtion personas is that your team start treating like real data, but, by The time this will happen, your personas will be based by data\n
When we have to create assumption personas we Find particularly usefull using emphaty maps.\nEmpathy maps are a tool for helping you understand who your customers are what they are thinking and what their feelings are.\n\nThere are different flavours of empathy maps and they can be used as debrief tool after collecting customer feedback or as a prompt that enables generation of ideas during a brainstorming session.\n\nToday we&#x2019;ll talk about the second kind:\nWe use empathy maps templates to help cross functional teams generating as many ideas as possible in the shortest period of time.\nThe categories on the template on this slide are not fixed, we tend to change them depending on the information we are looking for. So although the templates you&#x2019;ll find online will contain the same categories, if you use empathy maps for brainstorming sessions then we suggest you to shape them based on what you are after.\n
The workshop last 20min and it&#x2019;s repeated with different teams until you have gathered enough data to start building a skeleton of a persona. \n\n\nGet together a cross functional team, this team should be formed by The front line of your company. Try to gather people that speak with your customers on a daily base. accounts, support sales and managed service people are perfect for this workshop.\n\nBring them on The same room and spend the first 5 minutes explaining what the workshop is about, its structure, and what the team needs to do.\n\n\n\n
Go over the empathy map with everyone and ensure they understand the categories you've chosen. Then hand them post-it notes and Sharpies and give them 8-10mins to write as many items for each category as possible.\n\n This is done in silence and you should really stress the importance of quantity over quality.\n\nOnce the time is up, thank the group and send them back to their desks,. Document the result and clear the map, keeping all the post-it notes organised. Repeat this process with several groups.\n\nThese sessions will produce a huge amount of data, but it can be sorted pretty quickly using a method called affinity mapping which we'll cover later.\n\nDuring the affinity mapping stage you'll discover patterns and relationships between items that you can use to develop some assumption based personas.\n
In Lean UX the aim of each sprint is to do just enough to learn just enough to allow you work on the next iteration working towards completing the story. Think of the design as an experiment.\n\nAt the start of a sprint you need to define what are you aiming for at the end of the sprint, what your experiment will be. Agile has it's roots in development and favours working code at the end of each sprint. That's a good thing to aim for, but if you lack enough the information to continue, your sprint might be more research focused and discovery oriented.\n\nYour experiment might be ready before the end of the sprint - great. Now stop. \n\nDon't be tempted to add more functionality or add polish to the design. This is an experiment and the simpler it is the easier the results are to analyse. Any time spent polishing the design could be wasted effort if your experiment was wrong and the design needs to change based on new learnings.\n\nDon't get too attached or precious about your work, it's on the web, it's temporary it can and will change.\n\nSo you've defined this sprint&#x2019;s experiment and agreed that the team can achieve it within the sprint. Do you have enough information about the problem to continue? If not it's time to do some research - the lean way.\n
Ours is not a desk job.\n\nYou need to get out of the office and meet customers.\n\nField research allows you to test assumptions you've made and see how customers use your product. \nWork together with the team including devs and stakeholders to create a list of things you'd like to learn and questions you'd like to ask.\nWhat gaps are there in your knowledge? What would you like to know more about?\n\nWhat's a typical day? What do they struggle with in and what do they love in your product?\n\n\n but just like user testing make sure you aren't leading - never ask directly what the customer wants\n\nYou need to find some suitable customers, you may want a mix of new ones and those that have been using the product for a while or even potential ones. Maybe you haven't launched yet, so have no customers - visit that's get auedience. Write a screener so you can capture some demographic data and filter out some unsuitable customers. \n\nThere are a bunch of ways to recruit users and it's easier than you might think. You can recruit directly for your app, you can spend time with your company's CRM (or pester the person that looks after it), ask the sales and support team to help.\n\nContact each suitable customer and organise a good time to visit them in their office. Depending what you want to learn or the complexity of your product you could take anywhere from an hour or two to an entire day. Some UXers have even moved into a client's office for the duration of a project. \n\n
Bring a coworker with you. It can be incredibly rewarding for a dev to see a customer use the product they've built and builds empathy towards the customer.\n\nWatch the customer use the product, ask questions, listen to their comments. You need to adopt the role apprentice and your customer is master. Write notes about their environment, are they frequently disrupted? What over software and tools do they use? What's on their desk, have they created anything to aid them in their work (passwords or steps written on post-it notes on the monitor)?\n\nIt's important to remember that mostly, field research is about observation. It's easy to be heavily influenced by a vocal and opinionated customer, but much more important to see what they do. Perhaps their suggestion doesn't address the issue as well as they imagine or they are just having a bad day. \nYou'll see that people don't always say what they think, but they always do what they do - and you're right there to ask why when they struggle or do something unexpected. \n\nOften people will blame themselves before a tool, so not every issue is reported. People are inventive, and will create ingenious work arounds and they'll use your product in ways you hadn't thought of. They may also have requirements you may not have imagined and you might identify problems that you can help with.\n\nGenerally customers will love talking to you, and you'll return to the office with pages of notes that will help with your current sprint and future projects. Its important that this knowledge doesn't stay trapped in your notepad - it should be shared with everyone on the team.\n\nThese short informal sessions can be much more informative than several rounds of user testing and best of all, build empathy with the user across the team. We believe that involving coworkers in field research is amongst the most valuable things you can a UXer can do. An empathetic team is better equipped and incentivised to build great products.\n\nGet in the habit of doing this, ideally it's an ongoing activity occurring every sprint, eventually insuring that everyone on the team has been involved.\n\nEven if you are chained to your desk, you can still do some passive research, listen in on sales and support calls, trawl forums and twitter. \n
\n
\n
Seriously, when was the last time you were in a meeting that\n\nKept to a clear agenda\nDidn't overrun \nHad decent notes afterwards\nHad an outcome\n\nThey are handy for catching up on twitter tho.\n\nWe need a better way. \n\nRecently I combined two ideas from the book Gamestorming in order to extract ideas and problems from a cross functional team. This would create a prioritised list of issues that told me more about the problem. It took just over an hour.\n\n
All I needed was a different approach, cookies, post-its, Sharpies and sticky dots.\n
The process is simple, but its worthwhile taking a little time to prepare. Get there early, make sure the room is free, a comfortable temperature and you wont be disturbed, print all the material you require and make sure you have enough pens, post-it's, cookies, drinks and sticky dots and lay them out on the table.\n\nGet everyone settled in a comfortable room. Thank them in advance for their time, then take their phones, laptops and iPads off them. This may make them cranky, so now is a good time to offer a cookie.\n\nWhile they munch on cookies, explain the problem with as much detail and context as you have available. It's a good idea to have this written down, as you may forget to mention a critical detail and you'll want to print it out for group to refer to. Also explain the aim of today's session and the first step of the process. \n\nEncourage and answer any questions at this point, because you want to maintain focus and momentum during the rest of the session. Also they'll mostly be silent (yes, a meeting where silence is encouraged!)\n\nThe first step of the process is pure brain storming. Give everyone plenty of post-it notes and Sharpies and give them 8-10 minutes to write down as many ideas as they can and stick them to the wall. There is no talking during this time. The focus is on quantity not quality and nothing is too crazy.\n
Once the time is up, you should have a wall littered with post-it notes. Explain that the post-it's now need to be organised into meaningful groups. This process is called affinity mapping.\n\nAgain, set a time limit of around 8-10 minutes but this time talking is encouraged (but as a moderator, you should keep them on focused). They should discover patterns and define and label groups of related ideas.\n\nNothing is discarded, duplicates are stacked and ideas that don't fit neatly into a group are put into a &#x201D;parking lot&#x201D;. \n\nThe final stage is a round of dot voting. Count the number of groups and times it by 3. This will give you the number of sticky dots to issue each person in the group. A sticky dot is a vote, and each person has 3 to use in each of the groups. They are voting for the most important, most critical ideas in group. They can use all 3 votes on one, or spread them over a few ideas. This is also done in silence and you might want to impose a time limit.\n\nI love activities like this because they are quick, easy, cheap and effective. Each person involved brings unique insight based on alternative world view and their customer interaction, by collecting them together and using techniques like this you will generate many more ideas and develop a fuller understanding of the problem. They are adaptable and experimental too - maybe it should have all been talking or all silent, tweak the number of dots allocated?\n\nYour colleagues will like them too, because by including them in the design process you give them a sense of empowerment, they are fun, take them away from their desks. \n\nYou can do this kinda thing guerilla style, but asking head of departments permission before you borrow their staff is a good idea. Besides, being seen isn't a bad thing - people are curious and jealous when they see this going on and will ask questions or to be involved next session. By being visible, likeable and having allies in the company you can better evangelise our craft.\n\n
design studio is a collaboration tool that helps a cross functional team to generate a lot of ideas in a very short period of time\ndesign studio is made of 3 main components\n\n
during the creation teams are asked to generate as many ideas as they can through collaborative sketching\nduring the pitching processes participant present their design followed by the team critique\nNow let&#x2019;s see at what you need in order to run a design studio\n
First you need to put together a team\nIn a design studio the team needs to be cross functional. Running a design studio only with people coming from the same departments simply doesn&#x2019;t work. has been proven that cross functional teams often find more effective solutions to design problems and they do it faster.\nthe background of the team is flexible and based on the project, but in general alway try to have at least one business person a developer and a designer.\nAlthough this kind of workshops are usually run by designers or product owners, everybody can do it.\n
Second you need some tools\nyou need two types of paper: butcher paper to hang on the wall, and storyboards template with 4 to 8 boxes on it\nthis is an idea generation method where quantity is more important then quality, the thickness of the sharpies is perfect as it will make it impossible for your team to focus on details \nteams will be given a persona each, it&#x2019;s important that the team&#x2019;s designs around her goals and needs \n
\n
After the team has familiarized with the problem \ngive the participants paper templates and sharpies and ask them to create 6 to 8 concept sketches individually.\nThe paper templates can be used both to storyboard a flow and to sketch different solution for the same screen\nThe session has to be time boxed and each round of sketches should not last more than 8 minutes\nThis will forced them to focus on generating as many ideas as they can rather than details.\n
One of the best thing of design studio is that put everybody on the same level as they have been asked to do something outside of their con fort zone\nmost of the people taking part at these workshops have never designed an interface before.\nyou&#x2019;ll see junior level people design next to executives, both feeling equally uncomfortable \nJust make sure that this doesn't become a blocker, before the first round of sketches try to make the participants comfortable anyway\nexplain the dirty secret of design\n\n\n\n\n
After 8 minutes ask the participants to drop the pens and hang their sketches on the wall.\nDuring the pitching the team has a stand up and each member get 3 minutes to pitch their concepts.\nwhile member of the team is pitching her ideas no one is allowed to talk\n\n\n\n
After each member have pitched her ideas, the rest of the team get 2 minutes to critique the concepts.\nit&#x2019;s important to give the team clear instruction on how to run the critique section.\nThe critique needs to provide constructive feedback and is not about what a team like or doesn&#x2019;t like \nThe teams need to critique the design based on the goals the pitcher were trying to achive\n-----after reading the bullet points-----------------------------\nit doesn&#x2019;t really matter whether the team loves or hates the design concepts,\nThe members still need to come up with 2 to 3 positive comments and 2 to 3 improvements\neven if they think the design is perfect or totally wrong\n\nAfter the critique is ended, you repeat the process another time\n
Visual design could be a pain! In an agile environment we can&#x2019;t afford a big design effort upfront, whether your are start designing a brand new product or you are about to redesign your existing one, it's a bad idea. it&#x2019;s too expensive and risky.\nI know that As designers we used to design and document the look and feel of a product all in one go. We used to throw our psds along with pages and pages of documentations over the wall and then go to the pub and celebrate. the design phase was done. After one or two years we were then asked to start a redesign project.\n\nThe first reason why big design upfront doesn't work in agile is that not only creates barriers between designers and developers, but also between designers and designers.\nIf you walk in a room full of designers working on the same project the most recurring questions are:\nWhere can I find that file?\nWhat is it called?\nWhat is the latest version?\nWhat TKO_HP_V1.psd means?\nYou have implemented the old version.\n\nand this doesn&#x2019;t work anymore, how can you be agile when you are wasting time looking for files and implementing wrong versions?\n\nAlso \n
But when we talk about big design upfront we are also referring to redesigns. They suck. Redesigns are expensive, their impact is hard to measure and don&#x2019;t happen often.\nAnd they usually come with fucking styleguides that nobody read \n\nbut the biggest risk is that redesigns is that can have a massive user backlash. do you know when facebook redesign and everybody complains about it...never stopped and ask why?\nBy redesigning something all in one go you stripped the users of their tool knowledge, these guys go to sleep being able to use something and when they wake up, all the sudden they weren&#x2019;t able anymore, and they don&#x2019;t like the feeling, they don&#x2019;t want to relearn the tool from scratch and they will course at you on twitter\n\nThis is called the sudden loss of competency.\n\n
Becuse of the reasons and other reasons: designers now need better ways to deal with visual design in a agile process\n\nSo where should we start?\nAgile gave us the notion of incremental development, so as designers we need a way to constantly deploy small changes to the look and feel based on user feedback\n\nHow can we achieve that?\nWe need a central and accessible place where the team can find assets and be sure they are dealing with the right version.\nWe need a shared vocabulary so everybody to guess what something his by the way it&#x2019;s named.\nWe also need a shared vision on how we organized things so it is quick to learn\n
If you are working on a new project print out early stages designs and wireframes, or, if you are working on an existing product, start printing out all the key screens.\nThis workshop can&#x2019;t be time boxed as its duration highly depends on how many screen you and your team need to analyze, the complexity of the screens and the general state of the product.\nHang everything on the wall and get your team together, when I say team, I&#x2019;m not referring to a cross functional team this time, try to get in the same room a developer a visual designer a ux designer and if you have one a front end developer.\n\nLike in any other workshops explain the structure and the goals and get started.\n\nAlthough it could be a very long workshop the structure is really simple. with the printouts hanged on the wall ask the team to start drawing boxes around stuff. the goal is to identify elements and modules you want to evolve overtime globally. \nOk what is an element and what is a modules.\n\n
\n
\n
Once elements and modules are identified you can incrementally change the look and feel of you product without having to redesign the website.\n\nIf your app for some reasons suffer of some inconsistencies then you should highlight those at this stage. We usually consider inconsistent multiple pages that solve the same problem in different ways. When you find inconsistencies the first move is to try to see if you have already some modules that could adapt to the inconsistent screens, if not you then need to create new modules that can be used consistently.\n\nbenefits\nit saves a lot of time to everybody\nenable cross functional pairings \n
\n
\n
we&#x2019;ve covered a lot today, but these principles allows us to create more desireable products using a rapid collabrative process. \n\n
here are some books we recommend\n
\n

Just UX it up

Du liest eine Vorschau.

Hier ansehen

Just UX it up

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Just UX it up (20)

Aktuellste (20)

Just UX it up

Hinweis der Redaktion

Just UX it up

Du liest eine Vorschau.

Just UX it up

Empfohlen

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Just UX it up (20)

Aktuellste (20)

Just UX it up

Hinweis der Redaktion