Posts Tagged ‘ux’

23
May
2016

Lean UX Workshop with Jeff Gothelf – My top takeaways

by Sasha Ward

Last month I enjoyed a trip down to Brighton for a day long workshop with the author of Lean UX, Jeff Gothelf. UX enthusiasts from across the UK and some from as far as Sweden came down to the south of England to learn more about Lean, UX and all things in-between.

I’m going to run through my top takeaways from the workshop and explain how they can be applied within your product teams.

1.Don’t solve problems that don’t exist

It’s a waste of time, money and resources making solutions for problems that don’t exist. How do you know if a problem actually is a problem? Well, get out of the building (GOOB), talk to your users, ask them about their problems and observe their current behaviours or current workarounds. They might be happy with their current solution but you won’t know until you talk to them.

 

pop-corn-hoodie

Within your team, get together and write down your assumptions of what you think the problem is and create a problem statement that you all agree on (you can use a problem statement template – see Jeff Gothelf Lean UX).

2.Focus on the ‘M’ in Minimum Viable Product (MVP)?

Every organisation, every team will have a different opinion of what an MVP is, “a stripped back version of the final product”, “our must have features”, “version 1″ the list goes on…

What Jeff helped cement in my mind about MVPs was two things:

– that MVPs are for learning, not basic versions of the “final” product
– and they’re not restricted to digital means

Think of MVP’s as tests or experiments to gauge interest/viability of a certain feature or product. The first question to ask yourself is “what are you trying to learn?”, then ask yourself “how can we learn that by doing the smallest amount possible?”. At this point don’t be restricted by thinking that you can only learn by shipping a basic version of the final product. What you can do instead is leverage existing technologies/services/products in order to create an experiment to test your hypothesis by using methods like landing page tests, feature fakes or wizard of oz/concierge tests.

It’s important to set a threshold for success when creating  your MVP, e.g. when we see more than 100 clicks per day on this feature we know it is worthwhile to continue with this, or if 1000 people subscribe on our landing page test in the first week we will know we are successful. If you’re not clear upfront what what success looks like then how will you know when to stop the experiment?

3.Write tactical hypothesis statements

A hypothesis is a hunch, it’s our best guess of what we believe to be true. They are a great place to start when at the beginning of building a new product or feature, but remember they are still our assumptions so they need thorough validation.

They are quite tricky to get right as a good hypothesis statement is made up of a lot of variables with a lot of assumptions baked into them. They are usually comprised of a KPI or success metric, a persona, a user goal and a feature.

Jeff Gothelf has a great template in his book Lean UX that combines them all in a succinct way:

– We believe will will achieve [KPI] if [persona] will attain [user goal] with [feature].

The most valuable lesson I learnt from the workshop was to be tactical about how you write these, think about what is in your control and think about what you are trying to learn. If something isn’t in your control then don’t go ahead with it, have a rethink and move forward swiftly.

4.Start learning more

What I mean by this is, add stories to  your product backlog purely aimed at learning something or running an experiment. Treat learnings the same as you treat other user stories and get your team invested in learning more.

These can be treated in the same way as regular user stories, scope them, define the problem, write a hypothesis and go out and test it. In doing so you are likely to learn something you didn’t know before and it’s good practice at getting everyone in your team involved in the collaborative exercise of writing hypothesis statements and creating MVPs.

5.Getting buy-in to Lean UX in the enterprise

This was a topic that had a lot of interest from the attendees of the workshop and the best pieces of advice was to speak the language of the people you are trying to convince to buy-in to Lean UX and in doing so try to bring them closer to the process.

There is a lot of technical jargon that gets thrown around day-to-day and understandably it can be quite off-putting and intimidating. What’s important when trying to get buy-in to Lean UX in the enterprise is to speak the same language as the stakeholders and understand what they value. If their interests are in acquisition and conversion, then speak to them in this terminology, don’t start talking about progressive enhancement or typeahead as this will only cause more confusion and more unproductive conversations.

In summary…

We all aim to create great products that people need, and Lean UX provides us with guidelines to help move teams from doubt (assumptions) to certainty through evidence based decision making. As the UXer, start by getting your team on the same page by facilitating hypothesis workshops and design studios to help identify the problem and create actionable hypotheses that you want to validate through testing. You and your team will learn every time you speak to or test prototypes on your users so make sure you do this as frequent and early on in the process as possible, seeing as these are the people that you are designing for you need to create a dialogue with them as often as possible to ensure that you are on the right track.

Resources
1. Lean UX – Jeff Gothelf- http://www.jeffgothelf.com/blog/lean-ux-book/#sthash.Y6ULPslO.qI01GYOY.dpbs
2. Popcorn hoodie – http://www.ohgizmo.com/wp-content/uploads/2013/02/Pop-corn-hoodie.jpg
3. Feature fakes – https://www.industriallogic.com/blog/fast-frugal-learning-with-a-feature-fake/
4. Wizard of oz/concierge tests – http://www.usabilityfirst.com/glossary/wizard-of-oz-prototype/

This is only a brief summary of some of the things we covered throughout the day so if you’ve got any questions then please get in touch on twitter or comment below.

11
Apr
2016

Badger Digest – April 2016

by Alex Savin

badgers-on-the-run-600
Image by Chris Beckett, used with Creative Commons license

Fresh issue of Badger Digest bringing you the most discussed topics and links from our 100+ private Slack channels over the past month.

#DX

Links

Tools

One line news

  • Amazon EC2 Container Registry (ECR) is now available in the EU (Ireland) region

#Books

#A11y

#Conf

#UXD

#Nerdvana

17
Dec
2015

Attempting to reach actual reality

by Steve Cottle

really-header

 

Let’s do a usability test where we’ll take some participants and observe them with a product. We’ll take our findings and after a bit of analysis we’ll implement something. We’ll be able to base the development on solid research because we documented what the participants did and said. And that’s good.

Here are some things to bear in mind about usability tests:

 

Ironing out the creases
It’s good to practice. Practicing your test allows you to iron out any issues before they arise1. Imagine sitting down with your participant, you run through the first task annnd … they don’t understand what you’re asking! Oh no! All that time you spent crafting the perfect non-leading task and you have to rephrase what you’d like them to do. Will it be as effective as your original? Planning also means you’re not leaving everything to the last minute – printing stuff, getting equipment ready, sorting the room out and that.

 

Observation not conversation
As unnatural as it is, encouraging your participants to talk aloud2 about what they’re thinking gives great insight into why people find things easy or challenging. Also, try and avoid talking too much yourself. By the very nature of being a UXer, we want to help people achieve stuff so this is one that I personally really have to concentrate on. Avoid treating the session as a conversation and turn it into an observation3. Nielsen Norman Group has some good advice with their Talking With Participants article which covers three techniques (Echo, Boomerang and Columbo) that can be used in the test itself.

 

The whole truth?
So that’s all good. We’ve practiced and performed and now we can analyse our results.

Well hold on there Johnny-two-socks, the thing is sometimes participants might not be telling us the truth. Dun. Dun. Dunnn … There are several reasons why your results might be a little off the mark.

In UX Booth’s article Bridging the Gap Between Actual and Reported Behavior they have some insights into what could be going on in people’s heads.

 

1 – How would you like that answered?
Sometimes we answer questions in a way we believe the person who asked the questions would like them to be answered.  Similarly, we can answer questions how we believe to be socially acceptable … do we really exercise as often as we say we do?

 

2 – I’ll do what you do
There have been cases of participants straying completely away from what’s clearly a correct answer just to fit in with peers around them:

“[In the Asch conformity experiments] Research subjects were shown several lines of different length, and asked to select the two of equal length. The subject didn’t know that everyone else answering the question was a confederate of the researchers. The planted participants would sometimes unanimously give an incorrect answer and, 37% of the time, the real research subject agreed with them.”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior

 

3 – Self Image
People also say what they want to be true and perhaps not what is actually true, viewing their capabilities through rose tinted specs. Not so much delusions of grandeur, more wishful thinking:

“ … our self-image doesn’t match up to reality. But that self-image still influences how we respond to questions about our intentions, rationale, or preferences”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior

 

4 – Where and when
People respond differently in different contexts. For example there are more suitable environments than an office room to evaluate the usability of a sports app. The results from one environment would be quite different to the other4.

It’s not just about how people subconsciously answer questions. The very fact that people are being observed encourages changes in behaviour. The Hawethorne effect demonstrates that if a participant is set a task to complete while being watched by someone they might change their approach to completing that task. For example during an observation the participant may read through instructions leading to a more successful task completion, whereas if they were alone at home they may simply ignore them and fail the same task. There is also the notion that if a participant is asked to achieve a task then they presume that task can be completed. Whereas if they were using a new product outside of the test environment they wouldn’t know that what they wanted to achieve was possible and would enter a journey within the product to find out5.

 

5 – Ultracrepidarianism
People may also give you an answer to a question even if they they have limited knowledge of the subject just because the question was asked of them. And, if asked why they did something, sometimes participants simply may not know so they make up a reason, or offer their opinion anyway6. This is known as Ultracrepidarianism.

 

So …
Preparation will help things go smoothly and by applying some simple techniques during your test you can make the bits you have control over more successful. However the fact is, it’s inevitable that your participants will show some of the characteristics described above. The important thing is to be aware of them and to identify when they happen. You can’t control a participant’s subconscious or how much value they place on social acceptance and if you do become aware of anything which might skew things, note it down and advise how it may affect the results.

 

Usability testing tips
Here are some top tips for running a usability test courtesy of usability.gov:

1 – Be polite and make participants feel comfortable

2 – Help participants understand that you’re after feedback on the design. It’s not them that is being tested

3 – Remain neutral (refer to the Talking With Participants article)

4 – Avoid helping and leading the participant

[5 – Encourage participants to think aloud]

6 – Take good notes – there should be two of you, one to ask questions and the other to record

7 – Measure both performance (success, time, errors) and subjective (self reported satisfaction and comfort) metrics

 

Fancy joining the Red Badger team? We’re hiring UXers!

 

—————
References

1 www.nngroup.com/articles/pilot-testing/

2 www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/

www.nngroup.com/articles/talking-to-users/

4 www.uxbooth.com/articles/design-research/bridging-the-gap-between-actual-and-reported-behavior/ 

5 www.measuringu.com/blog/ut-bias.php

6 www.measuringu.com/blog/ut-bias.php

 

5
Jun
2015

Smooth Sailing- Designing businesses to deliver value

by Sinem Erdemli

“Improving experience starts with every customer interaction. Your customers see you as a one entity.” –Jiri Brezovsky

This is a quote from his post Stop wasting money on a “beautiful” interface it’s about the importance of improving the overall experience, rather than creating beautiful UI. It’s a brilliant and valid point, one which we at Red Badger think about a lot.

Even though a beautiful design, a high quality piece of software or sky-high conversion rates may seem like the ultimate goal of running a business, especially on a day to day basis, there is one crucial bit that shouldn’t be overlooked. That is to deliver value. 

I just want you to get the job done

As a customer, I don’t care about how well your metrics are doing, whether or not you’ve met your sales goals or when the next software update is due. 

I only care if I can get what I want from you or not. How much do I need to give [time, money, effort] vs. how much I get out of it. 

In the end, if I want to get my hands on a new computer I want to decide which one is for me, where and how to buy it, and how to set it up and who to get in touch when something goes wrong. All of that should be easy peasy, but is rarely so. 

The times they are a-changin’

Businesses have complex structures, they exist on multiple channels, partner with numerous 3rd parties and carry ways of working from the day they were established. 

A business runs with the help of multiple ‘departments’ ranging from marketing, sales, merchandising, customer services, online, suppliers, logistics. There’s also a big board of stakeholders to please with the outcomes.

“The problem [with designing in silos] is that customers don’t just care about individual touchpoints. They experience services in totality and base their judgement on how well everything works together to provide them with value” –Andy Polaine et al.

Each and every department has different targets and end-goals. They are usually focused on just one channel or a single touchpoint of the customers overall experience of a customer. The problem arises when the links between these individual touchpoints are left unattended, when they don’t appear on the targets because they are not tangible enough to make it to the boardroom. As a consequence, your customer’s experience with your business ends up being nothing but a broken, inconsistent and painful journey. 

When you think about it there is only one simple relationship to focus on, whether you’re in the boardroom, at the shop floor or in the office developing the website; and that is the one between you and your customers. 

 Love thy customer

value transaction

When it comes to deciding whether or not to come back, or to ‘recommend the service to their friends’ customers will not think about one interaction in isolation. They will think about how easy it was to use the website, how the staff treated them on the shop floor, they will consider the call they received by customer service team when their package was late all together. Overall their decision will depend on how easy it was to reach their end goal, the whole reason why they chose to get in touch with your business in the first place. 

Keeping the bigger picture in mind at all times will allow you to have meaningful conversations when you’re collecting requirements. It also will give you a reason to talk to each other, regardless of your position in the business. 

Stop and ask why how who

Before you get in your productive autopilot mode, stop and have a think about what the greater goal is.
-Why
are you doing what you’re doing?
How might you make it better for the person at the other end?
Who else might have an effect of the delightful experience you’re trying to create? 

Go speak to your colleagues, your stakeholders, customers. Involve as many parties as you can. Make sure you, as a business, are giving the same message, have the same tone and same level of delightfulness for your customers throughout their journey with you. 

Then and only then will your efforts count for something. Don’t forget, your profit, sales, conversion rates can only improve if you love your customer, try to make their journey with you as happy and valuable as possible because your customer will love you back. (and will most likely recommend you to a friend, if that’s what you’re after)

further reading

servicedesigntools.org has plenty of methods you can use to think about your business offer as a whole. I would recommend checking them out. Or have a read through Andy Polaine’s book Service Design, it is delightful and one of the best you can find around. 

let’s spread the love together

If you crave consistency in experiences and want to help businesses create value with beautifully designed high quality software get in touch. It doesn’t matter where you’re coming from, as long as your intentions are well:) 

30
Apr
2015

I heart pens and paper

by Steve Cottle

Pile of paper with wireframe sketches

 

I love pens and paper and putting them together to make marks and lines and scribbles and that. Lots of people tend to avoid them nowadays, favouring the tippy-tap of a keyboard and the clicky-drag of a mouse. A few years ago I moved jobs and was surprised to see some of my new colleagues taking notes by typing stuff into Word. Maybe I’m showing my age but that really can’t be a good way of taking notes. The office had a healthy supply of pens and all manner of notebooks to choose from. Still she punched away at her laptop. She certainly wasn’t the quickest typist in the world, how did she get everything noted down? How would she go back and make new notes around her original notes? How would she doodle the cup of tea she was drinking, or the sandwich she was looking forward to at lunch? What was wrong with her?

 

It’s all about the pens and the paper, people. The pens and the paper…

 

Easy peasy

The vast majority of us can sketch a line, with little to no training. Those who can sketch a line, can join the lines together too. Once the lines have been joined together, loads of options then become available. We can now sketch anything in whole world, simply by joining lots of lines together in different ways. Woah there, anything? Sure, remember sketching isn’t drawing. The marks on the page don’t have to be a photographic representation of what’s in your head or what you see in front of you. The purpose is to get the ideas out of your head and to communicate your thoughts to other people. Sketches are ideas. The sketch needs to be legible but in no way does it super polished. And it just so happens that if like me, you’re responsible for communicating ideas for stuff like processes, websites, apps, flows and journeys, the basis of our sketches are boxes. We just need to sketch the boxes. Who can go wrong with a box? And if you’re feeling a little sketchy at first – don’t worry, the more you do, the more comfortable you’ll become.

 

Feel the draw sketch

Once you start putting pen to paper a wonderful thing happens. You start to show people, you pick the paper up and turn it over, slide it across a desk, touch it and pin it to a wall. Now your sketches are visible and out in the wild for all to see and get involved with. Now other people are interacting with it and collaboration begins, the idea isn’t hidden away behind a computer screen – it’s ownership has been removed and it belongs to the team. Even jargon becomes watered down and a common language develops. You’re now not trying to remember the names of modules or functionality, you’re pointing things out and bringing them into the group.

 

As easy as they are to create, sketches are also easy (and fun!) to get rid of. Screw them up and throw them (literally) away, make paper aeroplanes from them, or even an origami swan. The interaction continues even when they’re on their last legs.

 

Pros and pros

Sketching is quick. You really can make a fair few marks on some paper while your colleagues’ computer is firing up and their favourite software is loading. It requires minimal setup and very little investment in time, training and materials. Also, you don’t need to match software across teams or make sure you have the right amount of licenses. The tools are available from loads of easily accessible places and sometimes for free (shops, lying around, Argos*).

 

*I don’t advise you use Argos as a supplier of free sketching material.

 

Something old and something new

Wikipedia says paper was invented by our Chinese friends during the Han dynasty (206BC – 220AD). It was the equivalent of modern day wrapping paper and bubble wrap – used to protect anything from mirrors to medicine. More recently Architects and Design Engineers developed this ancient packaging material by making it more translucent so drawings could be precisely copied. This process of tracing is one of the fundamental processes in Product Design. Iteration is key to getting closer to solving a problem, refining and developing an idea. With sketching you can grab a new piece of paper, trace the old version, and iterate a new one, again and again and again.

 

Hmmm, but …

Hold on there smokey Joe, we don’t want any of that “well …”,  “erm …”, “I dunno …”. It’s quick, fun and produces lots and lots of ideas. And it all started thousands of years ago in ancient China.

 

Here at Red Badger we open sketching up to everybody from UXers, Designers, Engineers and Developers to the users of the products we’re producing. And from a tinchy 20 minute session we can get a whole heap of ideas and potential solutions to the problem we’re working on. All with no training and no budget. And we all get a break from our computer screens t’boot.

So, go on. Tool up, get your pens and paper out and pull up a pew with your team.

24
Dec
2014

UX Tip of the week: Making UX part of the Process

by Sinem Erdemli

Design has gone a long way. Roles have expanded from being a last minute add ons to product strategy influencers. 

Design is no longer seen as the last step of a process that makes a product look pretty to defining product scope. UX design as a profession has been creeping in businesses, as ‘user needs’ start being taken into consideration at board meetings. Now, managers are actually curious about their target users. They want to understand what makes them tick and what is a turnoff. This is all great, but too early to call it a day and go home…

Mom are we there yet?

No. We’re still not there yet. We seem unable to shake off the industrial mind set no matter how agile we are. Our industrialised minds are still programmed to deliver efficiently, we want fast returns to our investments and love performance charts that point upwards. We most certainly don’t like cards that go back, against the flow. 

The question is: How can UX and design be integrated in the development process?

At Red Badger, we work in agile. That means we talk to each other all the time (occasionally about work stuff), we change things, we question the decisions we made, check in with users and do it again until it is right. The designers, developers, testers they all sit together and work together. 

However, that process of close collaboration is difficult to capture on the Kanban board. The project board is there for a reason, it should be a mirror to team activities, it should communicate the process and the goal we work towards. But does it really?

Out of sight, out of mind? 

The issue with keeping UX as an isolated step in the process is that once the stories pass through and get closer to Done, the goals change. After a certain point, the goal becomes efficiency and you find yourself focusing on just delivering features, making sure they pass cross platform tests. 

We’ve talked about how crucial it is to keep your personas close and introduced Bob. If you haven’t seen that post do it-here and now.

We suggested sticking a picture of your version of Bob next to your computer, on the wall, by the project board. Somewhere you pass, and will see-daily. 

ALWAYS keep in mind that there will be people using your product (unless of course your target group is animals, insects, aliens..) It is important to have check-ins with users. Just like daily stand-ups you have with the team or weekly progress meetings with your client, make sure you check-in with the end users, and take a step back to make sure the greater goals and the purpose of your project are still there. 

kanban

  • Discovery: This is a good point to discover why you should get started in the first place. Find out about the strategic goals as well as the technical feasibility. Test the concept, go and get a feel for what the intrinsic needs and behaviours are. What people might like doing, what do they enjoy, who do they follow and most importantly why they do so. Use this space and time to go wild. Explore and question everything.
  • UX: You know the drill here. Use all the wisdom you have to do your magic. 
  • Design: Make sure the design reflects the brand direction, the look and feel is consistent with your intended messaging
  • Dev: Check that the high-tech features make sense to people who will be using the product
  • Test: Try to find out the different use scenarios, validate the assumptions you’ve made
  • Done: Watch usage, do some proper testing, measure and watch behaviour. Use all the data you’ve collected to write up new use cases, start thinking about improvements 

Disclaimer: We’re still testing this out. It’s already changed within a week. The user testing section doesn’t have to be a physical test with users, . 

It’s merely a suggestion rather than a solution- as always. Do try it at your own risk- we suggest collaboration over supervision. 

Until next time..

Ta!

17
Dec
2014

UX Tip of the Week: Meet Bob

by Maite Rodriguez

 

From the developers to creatives to business people, how to get everyone to finally understand the what UX is really about.

 

Let’s get started.

 

I would like to introduce you to Bob.

 

He will be our “user” for today.

 

 

Bob = User

 

For starters, you should always make it clear it is all about the “user” aka Bob.

 

Period.

 

If this is not absolutely clear from the beginning, then there is no point in reading the rest of this …..

 

Ta!

 

 

Stop using the term “user” to the team. These “users” are people with feelings like Bob. Try to use the persona’s name that the UX team meticulously researched and created for the brief.

 

Personas are there for a reason….

 

If you have to, frame a photo of your persona, let’s say Bob, and place it next to everyone’s computer as a daily reminder.

 

 

Let’s make this abundantly clear, people are not “stupid” or “slow” or “lazy”.

 

If your “users” do not understand the design, it is 99.999999999999%everyone’s fault involved in the project.

 

One team, One accountability.

 

 

If you are not there to defend the “user” … then who will? If there is no one representing Bob, then there is no UX.

 

 

Do not resort to the easiest tech solution. I know, it’s hard…

 

Mo’ work, mo’ problems.

 

But, if it’s for the “user” aka Bob’s best interest sometimes we all have to make sacrifices. As that great kung fu fighter once said in that kung fu movie:

 

“Take the hard righteous path than the easy wrong one to save the kingdom.”

 

 

UX is not like paint. We can’t just slab some paint on a chipped wall and call it a day. It is much more than that, so much more.

Here’s in on little insider secret…. UX doesn’t really exist.

 

UX is just a easy term that is used to group a whole lot of things that would take too much time to explain in one simple job title.

 

 

So, if you just take one thing from all of this, remember:

 

Every code written, every interaction made, every word read, every visual seen, the “user” should always be taken into consideration.

 

So, today I will rename the term “user” to “people” because it is all about the people’s experience…. Bob’s experience.

 

Until next week….

Ta!

 

10
Dec
2014

UX Tip of the Week: Post-its

by Maite Rodriguez

The Magic of Post-its

 

 

Post-its, Post-its, Post-its, Post-its, Post-its evuuuuurrryyyyy where..

 

All you need is a pen, wall space and post-its for your inner genius to come through.

 

When should you resort to post-its you ask?

 

  • Feeling overwhelmed with all the initial research and don’t know where to start….. post-it

  • Creating a christmas shopping list that you still haven’t started …. post-it

  • Need to do a feature analysis for a competitive website… post-it

  • Takings note at a meeting… post-it

  • Preparing a plan for action… post-it

  • Can’t decide where to eat for lunch…. post-it

  • Weighing the pros and cons of anything really… post-it

  • Need to prioritise and MOSCOW your project… post-it

  • Explaining to you co-worker how to get to Dirty Burger… post it

  • Trying to understanding foreign concepts (aka not related to UX) …..post it!

 

See! I challenge you to find a moment when the post-it can’t work its magic.

 

 

Until next week…..

 

 

 

4
Dec
2014

UX tip of the week: Competitive analysis for mobile navigation

by Sinem Erdemli

We started the week with user testing on an e-commerce site. It was all good until we asked people to find something, they had no idea how to work the side navigation.

And that was a surprise. 

tumblr_ltnymfq4NX1qen75u

It was obvious that users were struggling with it and it wasn’t a batch of those users who can’t work anything and have no idea what’s going on. There’s a limit to how much you can blame users.

The question in hand was obvious, one we had been pondering on for a while:

How might we get the benefits of a a mega nav on mobile?

So we went back to the office and got our post-its out. (Keep your eyes peeled for our next post on why post-its are king)

It was time to take a step back and clear our muddy heads. 

The game plan

1- List out relevant websites that have a similar issue (in our case it was squeezing mega nav content into mobile navigation)

2- Collect screenshots, the more you have the more ideas you can “steal” nope not that.. borrow

3- Break down the screens into it’s components. This is where the mighty post-it comes to play. 

4-List out Pros and Cons for each. Identify your favourites.

5- Sketch out the flow for each, find out how the users are lead to a particular Product Listing Page. How soon do they see the content? 

6- Compare flows. Visually comparing the flows let you highlight differences at a glance, it helps understanding (and communicating!) what works and what doesn’t. 

flow

6.a- If you can, go out and test the few examples with people, see if any alternative stands out, find out what people think. 

7-Show this to any stakeholder, it may be the client, it may be the designers, the dev team.. Talk about the issues users has, show the comparisons, think about what’s possible what needs more exploration..

8- Identify what you like, what can be done, with a little help from the favourite features list- and try it out. 

Taking a step back and looking around is useful. You clear your head, benchmark yourself among others and get to spend some play time.  Try it, you’ll feel better. 

Until next week, 

Ta. 

28
Nov
2014

UX Tip of the Week: Guerilla Testing

by Maite Rodriguez

What we learned this week:

Guerilla Testing

How to approach people and lower your chances of being rejected.

 

 

Do

  • Choose a location where people in your target audience are likely to convene. In our case it was a Co-op working space.
  • Go right at the end of lunch time when people have finished their food and are more likely to crave sweets.
  • Bring candy, brownies, cookies… get creative and place it next to your working space. Try to avoid being creepy. A fan to blow the smel may help catch their attention. Kidding!
  • Smile and ask if they have time to spare. (The amount of time you will be user testing)
  • If they say no let them walk away. No begging.
  • If they say yes, game on.
  • When you ask them the pre-screening questions and find out they are not your target user, its okay to cut the testing short.
  • Take notes. Voice recorder, video recorder or just a plain old note pad.
  • ASK PERMISSION before you do a voice or video recording!
  • During the testing. Watch, Listen, and ask follow up questions like:
    1. Why?
    2. What did you expect to see?
    3. How did that make you feel?
  • After 3 users it starts getting tiring.
  • Go home.
  • Next day, review notes and find the trends.

 

 

Don’t

  • Just show up with nothing prepared and wing it.
  • Lie and tell them it will take them 2 minutes when it will actually be 10.
  • User test anyone who is willing to talk to you.
  • Invade their personal space once they are close enough.
  • Creepily stare them down as they walk towards you.

 

http://giphy.com/gifs/black-and-white-smile-horror-XQLcriSh7za0w

 

The end