Category Archives: UX

Using Skype for Moderated Remote Usability Testing

By | Research, Uncategorized, Usability Testing, UX | 7 Comments

I used Skype and Ecamms Call Recorder for Skype to conduct moderated remote usability testing around the world on a clickable Marvel app prototype. Heres how I got on.

I’ve been working for a Japanese sportswear company who wanted some usability testing done on a new feature they were planning for their fitness app. As the app has a healthy (pun intended) global user base they were keen to test with users from around the word which mean’t remote usability testing on a clickable prototype put together in Marvel app.

When I’ve conducted moderated remote usability testing in the past I’ve used screen sharing services like Webex and GoToMeeting but I’ve always found the requirement on the end user to install various plugins troublesome and the cost (at the time) was prohibitive.

My loose set of requirements this time around was:

  • No plugins to install
  • Low cost
  • Reliable
  • Record screen, audio and video of the participant

I settled on Skype in the end as its pretty ubiquitous these days and although the app would need setting up and installing the chances were that a lot of respondents would already have it up and running.  Because I had a few thousand potential participants I took a gamble and was explicit in the screener recruitment survey that we would be using and Skype on a desktop or laptop and this was a requirement. Despite this I still got a 20% response rate which was better than I normally get for face to face interviews (what also helped was a fairly loose set of requirements for participants and also doing the tests over the weekend).

Skype doesn’t have an inbuilt recording capability but there are a few plugins that can allow this. I used Call Recorder for Skype by Ecamm and at $29.95 was pleased with the results.

What went well with the testing:

  •  Low barrier to entry mean’t that I got a good response and including Skype as a requirement didn’t seem to put people off
  •  Not having to mess about with talking people through installing plugins on the day took a lot of the pressure off me and allowed me to focus on the testing
  •  The call and video quality was excellent so I was able to include excerpts in the final presentation deck for the client
  •  Conducting the testing at the weekend meant I got a good response and because it was remote meant I could spread it out over a couple of days without having to hire meeting rooms
  •  People seemed more at ease with the test and opened up a lot quicker because they were at home
  • It was cheap to run compared with hiring meeting room space

What went less well:

  •  Skype wasn’t quite as flawless as I hoped. Two out of the five couldn’t share their screen without Skype crashing.
  •  I also had the call drop a few times for no particular reason which was annoying and interrupted the flow

So would I use Skype again? Probably yes. Despite its flaws it was pretty easy to use for the participants and although its no substitute for face to face interviews it was still pretty effective and I got lots of good feedback. Conducting it over the weekend wasn’t ideal (for me!) but mean’t I could talk to more people and turn around the test results quickly.

5 years on … Lessons learnt from my time in the freelance UX trenches

By | Freelance, Portfolio, UX | 2 Comments

Five years ago this month I quit the comfort of my full time job and went freelance. I often get asked  about how to go about becoming freelance so I thought I’d mark this anniversary by listing a few things I’ve learn’t upon the way (in no particular order):

1. If you’re going to go freelance do it properly

When I left my full time job I spent the first 6 months not really sure whether I wanted to go perm or go freelance. The result was a bit of a mess of me half applying for jobs and half committing to the freelance life. In hindsight I should have focused more on the freelance thing and set myself a deadline where I could reassess my career.

Remember you’ll also need a few months money to live on while you wait for your first invoices to be paid. I had some inheritance so I gave myself 3 months to make a go of it. My plan was that If after the first two months It all went horribly wrong I’d still have a month to find a permanent job. I still have that money in the bank.

2. Find a mentor

I’m lucky that I know a lot of freelancers. When I first started out I found it really useful to meet up with them from time to time and pick their brains about freelance life and what I should be doing. Its worth getting to know some freelancers (doesn’t matter what line of work they are in) just to sense check your decisions and sound them out for advice.

3. Get a website 

I’ve had a crappy website for years. This year I spent a bit of downtime at the beginning of the year updating it to something only slightly less embarrassing. The result of which is that whereas before I didn’t get very many work enquires from it I now get 1 a day on average.  Wish I’d done it years ago. I bought a WordPress theme and hacked it about to meet my needs but you are probably much better at coding than me. Have a look at other freelancers websites for inspiration.

4. Get a (meaningful) portfolio

There have been plenty of people blog recently about the value of UX portfolios but I can talk from experience of having been on both sides of the hiring table that it is worth spending time on one. Just remember that nobody is interested in a list of projects with shiny screengrabs and Photoshop mockups. What hiring people want to read is a story about the projects you worked on starting with the objectives, what you did on the project and the outcomes. (I’ve got a longer blog post drafted on this which I’ll save for another time)

5. Use LinkedIn

I have a love hate relationship with LinkedIn but the fact is that I get a lot of work out of it so spend the time honing your profile. Think of the kind of skills people will be looking for an get those key words in your profile. Also keep the copy tight and to the point and use bullets to highlight key skills.

6. Network Network Network

Get along to as many networking events as you can. The UX (and web industry generally) is a friendly space to be in so get to know people as you can. I quite often pass work onto people I know if I can’t take it on and the reverse has happened to me as well. It also doesn’t hurt to do a few talks and get a bit of a name for yourself if you can.

7. DON’T PANIC

Some months are lean some months you’ve got work coming out of your ears. You can’t predict how much work you have so don’t bother trying. The only things I noticed is that from mid December to mid January things are quiet and also things quiet down a bit in August. Also remember that you are not a machine and take time off. Work will always be there when you get back.

8. No job is ever guaranteed

I’ve learn’t this the hard way but it doesn’t matter how many contracts you’ve signed no work is guaranteed so be prepared. I’ve had projects stop a couple of days before they were meant to begin and half way through (nothing to do with me!). Unfortunately it comes with the territory so make sure you’ve always got a couple of months money in the bank just in case it happens to you.

9. Keep track of your finances

Its much easier to sort out invoicing, expenses and tax as you go along rather than leave it to the last minute. I try and keep a 1-2 of hours a week to one side just to keep up to date on admin. There are lots of finance packages out there but I recommend Freeagent (heres a referral code if you fancy giving it a try for a 10% discount – 33n0dtl2). I know some people use spreadsheets but for the money its worth having something like Freeagent to streamline the process and leave you a bit more time for the more important things in life.

10. Set your rates

Don’t ever try and be the cheapest. Sell yourself on producing quality work and set your rates accordingly. I have a sliding scale of rates depending on who the client is, what the job is, where its based and how long its for. Having said that I tend not to worry about money too much. I do this job because I genuinely love it and would rather do an interesting project than work on something well paid. If your main motivation for becoming freelance is earning loads then there is plenty of well paid work in the finance and gambling areas.

11. Get your game face on 

You’ll be expected to hit the ground running when you start a new project and the people in your team will be looking to you for the answers. I rarely get to work with other UX people (when I do its a treat) so nobody will be there to cover your back. If you are serious about becoming freelance make sure you know your trade inside and out. There will be lots of occasions where you will need to learn as you go along but when you do this make sure you’re not making too much of a leap into the unknown as it will come back to bite you.

12. Dont be the Flash guy

Remember Flash? Don’t be that person who still only does that one thing. Try and keep ahead of the game and keep your skills sharp by reading blogs, following the right people on Twitter and going along to talks and conferences.

13. Document and record everything

I generate a lot of paperwork and sketches. I try and keep a record of everything I do for my portfolio and to evidence my work in case anyone ever asks why certain decisions have been made. I don’t keep hard copies but I photograph everything and file it away. You never know when it will be useful.

14. Find your preferred way of working

Theres no right way of working or type of project, its whatever suits you. Some UX freelancers prefer to work on retainers or will only work from home. I prefer working on bigger projects full time and generally work onsite. Its just whatever works for you.

So there you go, a few things I’ve learnt along the way. I hope if you are planning on making the switch you found this useful. At the moment there is still plenty of work to go around (especially for experienced people or those with specialisms) but the market is becoming a little crowded as more people make the switch. Fortunately as the industry becomes more established so does the quantity of work available so its still a viable option.

There are probably lots of things I’ve forgotten so feel free to ask and buy me a beer sometime and I’ll tell you all the sordid secrets!

Good luck!!

The problem with Lean UX is …

By | Agile, Lean, UX | 2 Comments

The other day I wrote a quick response to the question ‘What are the weak points of the Lean UX design methodology?’ on Quora. A couple of people have asked me to explain a bit more about my post so I thought I’d elaborate a little.

The app I’m currently working on is focused on developing a Minimal Viable Product (or MVP)  for use in schools. Unfortunately the project has had strict time and budgetary constraints imposed on it so, from the outset, there was a real pressure to deliver as many stories as possible in the given time. (In a true Lean environment MVP wouldn’t be a deliverable as it is here but a state of flow but thats the situation we have.)

Due to the restrictions of this project its concentrated a lot of the Lean UX implementation headaches into a short period of time which prompted me to write this post.

One of the many problems with the ‘feature first’ approach is that in order to include as many features as possible any UX and design consideration is stripped so far back whats implemented could have a negative impact of the usability of the feature in question. While none of the changes made are huge compromises the cumulative effect can be damaging to the experience of using the product.

The other problem is that in order to deliver as quickly and efficiently as possible any delighter or exciter elements often get removed in order to fit the feature into the sprint. Once that happens there is almost zero chance of it ever getting retrofitted.

Andy Budd summarises the problem well in this blog post from a couple of years ago

“In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.”

In order to mitigate this problem each story or feature should come from the users themselves and should have a hypothesis which we, as a team, should seek to validate.

For example say I wanted to introduce a new brand of ketchup to the market. The hypothesis could read something like:

“We believe that lovers of spicy food will want to use our new brand of super spicy ketchup as a condiment with their food.

We will know this to be true when:

– We see a week on week increase in sales of our ketchup in supermarkets

– Our customers tells us they like the taste”

(not a great hypothesis but you get the idea!)

To continue with this rather clunky analogy – If we imagine that our ketchup is in the wild and our test supermarkets put it on a high shelf, out of reach for most people, we would probably find that hardly any ketchup is sold. From this you might assume that no one wants the new ketchup and the product is a failure. If however you put the same ketchup on a shelf which is easier for people to reach then we may find that more people buy it and our hypothesis has been proved correct and people love super spicy ketchup.

The point being if the feature we our trying to introduce isn’t given a fair chance by being implemented as well as it could be then we shouldn’t be surprised if hardly anyone uses it and its widely ignored.

So whats the solution? Well the bad news is there isn’t a silver bullet which will cure all the ills, more a few things that, if implemented well, may help.

  • Better integration between the devs and UX. This first one is a no brainer. Work together to design easily implmentable features with minimal overhead.
  • Spend more time talking to the PO so when they are grooming and prioritising the backlog they have the full picture and understand what the implications of their decisions are.
  • A key hypothesis for new features. What problem is this feature we’re implementing solving and how will we know when its succeeding? Include a hypothesis not just for the product but for each story and also include a KPI to test that its doing what its supposed to. Which leads nicely onto…
  • Once a feature is live keep testing it. Keep questioning its validity and seeing how the experience of its usage can be improved for the end user. Schedule points to revaluate features and see how the experience could be improved through iterative design.
  • Ditch the burn down chart. Burn down charts are only useful for management types who like graphs. The proof of progress should be in the features and stories which you’re pushing live which users using. (Theres a blog post in there somewhere but I’ll save that for another day!)
  • Continuous deployment – Don’t wait till the end of the sprint to release new stuff. Release early, release often.

Theres probably a bunch of other things that you could do but thats all I’ve got for the moment.

For the record I love Lean and Agile as a process for designing and building products, it just feels that sometimes in the excitement of getting stuff out there, we lose sight of the detail which separates the ok products from the great ones.

Empathy Quoting – A new take on the Risk Register

By | Agile, UX | No Comments

In the bad old days of Prince 2 project managers would cobble together a document called a Risk Register. The purpose was to try and predict anything that could go wrong with a project and then come up with a plan to mitigate the problem. While the sentiment was sound these documents were focussed around business need and (in my experience) were rarely designed with the user in mind. They are also (by their nature) very negative, which isn’t a great way to start a project!

Newer Agile and Lean methodologies do away with the need of the Risk Register because the iterative nature of development means that the project can roll with the punches but I still believe that getting the project team to give some thought to possible project outcomes (both positive and negative) isn’t necessarily a bad thing.

With this in mind I designed a quick workshop exercise that I used last week during the final stages of Sprint 0. Feel free to adapt and let me know if you have any suggestions. (Hat tip to Gamestorming from where I borrowed the game format)

 

TITLE – Empathy Quotes

 

OBJECTIVE – The objective of this exercise is to get the team to think of possible user reactions to the launch of your product. It also gives all team members a chance to air any possible concerns they have before a project starts.

 

NUMBER OF PLAYERS – 3-10 (if possible include all the project team including stakeholders)

 

DURATION OF PLAY – 15-30 minutes

 

HOW TO PLAY – Firstly get the team to identify all the parties who have an interest in the outcomes of the product and write these up onto a whiteboard. (The product I’m currently designing is for schools so our groups included students, teachers, parents and, because of the business importance, we also included senior stakeholders.)

Next hand out sticky notes to all of the team and then give them 5 minutes to individually write down as many likely quotes as they can think of from all the various parties both positive and negative.

When the 5 minutes is up get the team to take turns to read out their quotes and encourage the team to discuss their thoughts on the quote. The quotes can then be posted up under the various party titles and duplicates can be grouped.

 

Empathy Quote Board

Real example of an Empathy Quote board

Close up of the quotes

Close up shot of some of the quotes we captured as part of the workshop

STRATEGY – Get the team to talk about the quotes and give special attention to areas where the quotes have been grouped. Get the team to think about how they can capitalise on the positives and possible strategies for coping with any negative issues that may arise further down the line.

Keep hold of the quotes for the end of the project as they could also be used to refer back to when the product is launched.

 

Looking for UX design and research help with your project? Get in touch