These questions came up in a recent round of Drop in Surgeries that I held and I thought they may be useful to share.

1. How do you test an idea where you are creating a desire, rather than providing a solution to a problem? 

Firstly, you need to work out the user’s context: where are they / what are they doing at the point that your product becomes relevant to them.  When you think of it this way, you may realise that you are giving them a more efficient / more entertaining way to do something that they already do.

Next, you need to work out how you simulate the experience so that they understand what your product/service does. What level of prototype do you think that you need? Less is more. If you can get away with a paper prototype or even a storyboard of the experience, all the better. Do you really need to go as far as to create a beta of the product? Then you can follow the advice that I give on how to set up and interact with people to get valid and useful feedback. 

2. How do I work out what features to include in my product?

Think about who your target customers are. You should have a number of different personas that you are using to help you focus. I suggest no more than 5. Who are your core target segment? Do you have 1 or 2 that you can “bullseye”? If so, you can run feature prioritisation exercises with them. This works well in a group session where you can also test brand, look and feel.

So you ask them to make a list: “What do you think that this product should do?” Then you show them what the product does. Next you ask them to prioritise all the features on both lists and come up with one list of prioritised features (and not to prioritise anything that they do not care for). Run this individually first, then try and get the group to come up with one agreed list. It is the conversation that is really important for you to listen to. You can also ask the group where the line is between the “must haves” and “nice to haves”. 

If your product is already live and you have an active engaged base, you can run this exercise online, asking respondents to put features in order of importance to them and then offering a free text box for anything that is missed out. It is a slightly different result, as you cannot easily get them them to prioritise anything that is not already in your list, but very useful for getting user input to your feature roadmap, especially if you are trying to develop the customers that you already have. (Short answer!)

3. Will I really be able to run my own research as you suggest in the DIY workshops?

Well this is the challenge. The Princeton professor that trained me said I would never be able to do it. She said that I was too passionate about my product. I knew that being able to carry out research with customers direct was going to improve my performance as the product owner so I was very determined. I proved her wrong.

There are a number of core skills that you need to carry out effective user interactions; that include being able to put people at ease; being totally impartial and being able to listen. Not everybody can do it. If you can, then great. If you can’t then find someone else to do it for you. Don’t opt out all together. If you are trying to keep costs down, you may still be able to write the brief, just find someone else to run it for you. I have plenty of other tips on how to do as much as you can on a budget, but still get valuable input. Please get in touch if you want to know more.

OTA 2013 – 5 year Reflection

Over The Air is coming around again – so time to think about what I will bring to the party this year. It is one of the few annual events highlighted in my calendar (other than birthdays!), so unlike most people, who reflect around the start of a new year, my point of reflection is Over the Air!

So it started me thinking, how far has my campaign to put users at the centre of technology been going? Did I succeed in my personal mission to be entertaining and insightful?

OTA 2009 – Yes, I am right, technologists realised they were not engaging users early and often enough (and also are up for a bit of fun!)

Panel photoAt OTA 2009 I got to further test out an idea that I had been toying with by putting a panel of young people on stage to offer their reviews of a number of products that were pitched to them. The feedback I got certainly proved the point I set out to make:

“…These teens are giving the best hints on marketing and product development I’ve heard in a while…strong feeling people are better at presenting their new technology rather than the benefits and users of it…better than venture capitalists when it comes to grilling the presenters…”

Here is a link to the full report I wrote under the banner of “The Digital Youth Project” collating input from a number of panels and pieces of client work, pre and post OTA 2009:

OTA 2010 – Product Doctor Surgeries are launched

By OTA 2010, I had moved on to establish a new name: “Product Doctor” (good story as to how that came about which you can ask me about some time!) and in keeping with the title, offered up Drop In Surgeries for the first time. One on one consultations with walkaway prescriptions. Found to be useful by patients, I have repeated that each year and each year I write up my findings.

Product Doctor Surgery, OTA 2011, courtesy of Paul ClarkeOTA 2011 – Surgeries prove popular – advice areas seems to become repetitive

As I was writing up the output, I seemed to be giving advice around the same areas, so I decided it would be a good idea to write a “how to” guide.

OTA 2012 – Patients are given a DIY User Engagement guide this time


During the Summer of 2012, I was asked by UCL Advances and Mobile Monday London, to put together an evening programme with industry experts teaching business, design and need-to-know aspects of technology over a 10 week period for people that are developing new ideas. Yes! My campaign could continue – best practice is of course, user-centred design, and over the past two programmes, I have turned the guide in to a series of practical “how to” sessions, that have been well received by the participants. Our 3rd certified CPD programme runs from 1st October – 3rd December – book here: http://moblacad-2013-10-01-JS.eventbrite.com)

OTA 2013 – DIY User Engagement becomes a practical “how to…” session, oh and of course, Product Doctor Surgeries are on offer again…

  • Session: Friday Morning time TBC.
  • Surgeries: Friday Afternoon: 14.30 – 19.30

For OTA this year, I am going to deliver a session that pulls on the material I have created for The Mobile Academy; it is an interactive demonstration on how to get user feedback – doing it yourself.  Starting with the why and moving to the when and what: this session will show you how to engage users to test out early stage concepts, get feedback on how you look, help you prioritise your feature lists and to work through how usable your product is.

1) Do you have a product I can use as a Case Study for the session? Criteria: Must be able to find at least 4 target users for your proposition in the audience; must have a logo and either have a website or a page in an App Store.
2) Would you like a consultation? Email me direct for a 30 minute appointment: julia@productdoctor.co.uk


Been making noise over there!

TheMobileAcademy-Logo+TaglineLack of posts since July as I have been busy developing The Mobile Academy programme for UCL Advances and Mobile Monday London.  I write on the launch day – big surprise, awake at 4.30 am!   The programme has sold out and there is already a substantial waiting list. (Read more about the brand creation)

The programme is a 36 hour masterclass in how to make it in mobile, delivered by industry experts (many from the Mobile Monday London community) across design, technology and business.  It is a great fit with Product Doctor in that it is going to provide very practical information, with hands on sessions ,where participants are shown a number of tools that they can start using immediately.

Host Logos UpdatedTHE MOBILE ACADEMY embraces approaches and ideas inspired by:


  • experiment & problem solving
  • form follows function
  • unity of design & technological innovation
  • streamlined, simple elegance




You can follow progress on Twitter @Moblacad and also check out the News page.

The Mobile Academy is hosted by Mobile Monday London and UCL.

UCL Logo

Mobile Monday 10cm wide hi res

Inclusive & Accessible Design



Here are some main insights from a blogpost that Katrina, my Product Doctor colleague, wrote for Mobile Monday London, based on an event that they held in June.

Inclusive Design – The User IS You

Inclusive Design (ID) and Accessibility, and the design principles around these issues, are not confined to a ‘special group’ of people. The notion of good usability is essential to the design of successful mobile products – if not all products – not only for those with a particular capability loss, but for everyone.

The British Standards Institute (2005) defines ID as, ‘The design of mainstream products and/or services that are accessible to, and usable by, as many people as reasonably possible … without the need for special adaptation or specialised design.’  There are 62 million potentially disabled users in the UK – that this is actually the population of the UK, because whether you are permanently or temporarily disabled with a broken wrist, there is a high probability that eventually you will be affected by accessibility, so it is not just about your users, it is actually about all of us.

Worth reading Henny Swan’s blogpost for agnostic guidelines for developers which contains the presentation she gave.   Following Henny’s presentation, we were treated to a dynamic and interactive discussion – just as we’ve come to expect from a MoMo event!

The panel, chaired by Robin Spinks of the RNIB (Principal Manager, Digital Accessibility), was joined by:

* Damon Rose (Ouch! Podcast producer & BBC News journalist)
* Suzette Keith (Usability and Accessibility Researcher & Visiting academic at Middlesex University). Suzette declared herself, firstly, as “…the representative old person…” at the event and although she didn’t have a smartphone “…I am not alone. I did some work with Hackney Silver Surfers…and out of 12 people one person had a Blackberry, she used it as a phone.”
* Samantha Fletcher (Trustee of the Dyslexia Association of Bromley, Bexley, Greenwich and Lewisham). Samantha also sits on the British Dyslexia Association’s new technology committee. She has quite severe dyslexia, mild dyspraxia and mild A.D.D.
* Former journalist Paul Carter (Co-Director of markthree media). Paul, who was born without arms and legs, joined the panel to talk around people with dexterity issues and mobility problems.

Which? Most helpful Apps  

Asked which apps the panel members found most helpful, it was a clean sweep for apps that were considered most practical and took some of the stress out of everyday tasks:
* For Paul, the move towards contactless and mobile payments, and Hailo (black cab app) – he described as ‘life-changing’ for people with dexterity issues;
* Robin also likes Hailo and apps that are good for the visually impaired (VI): Ultra Magnifier, dictation apps, train times and the Next Bus app;
* Suzette – A standout app for older people is the Transport for London Journey Planner. This also helps reduce the cost of travel for those users not yet old enough to qualify for a free pass;
* Damon – “Blind people have the best technology!” – likes the light detector app on his iPhone;
* High praise from Samantha for trainline.com – ‘amazing’, the calendar app –‘brilliant for recording everything’. She thinks that, for Dyslexic users, Google beats a dictionary app as the latter requires correct spelling whereas “With Google you can put any rubbish in and somehow it always knows what you’re trying to say.” Google Maps are also a favourite, although, as Samantha pointed out “One of the downsides is if you want to turn the map so you’re looking at it as you’re standing, it will rotate with the phone.”
Yet, I’d suggest that this particular feature is annoying to a much wider populace (me for one) who isn’t particularly good (read: rubbish!) at navigating. Which is why, as Paul described, it makes sense to remember that “Anything that makes anyone’s life easier is going to make life even easier for someone like me.”

Essential Tips – 4 things to remember when developing Accessible apps

Then asked for advice for developers to help them create more Accessible apps, the panel offered some excellent tips:

1. User Testing – There is NO substitute
When it comes to making apps more Accessible, Damon Rose advised “Testing with real life users who have a range of impairments is really the biggest source of guidance.” On the issue of all-encompassing standards for developers to deliver Accessible applications, Suzette Keith said that given the rapid speed of development in the mobile space, it would take a while for Accessibility guidelines to catch up. So “In the meantime, doing your own user trials is going to be your best route for discovering what really needs to be done and tailoring to your particular application… The more that you talk to people and the more you get feedback from individual users and from other developers, you’ll actually begin to build up your knowledge and your confidence in terms of delivering some of this until such a point where you just deliver it without even thinking about it.”
Robin Spinks’ recommendation to developers is to seek out feedback from users. He urged them to “Encourage people to tell you about how Accessible is your app. There are lots of people out there who would love to do that and, quite frankly, buy your app if it’s easier to use.”
The case for user testing was also echoed by Henny Swan “There is no substitute for testing with users across the board but I think in mobile we are at the point where we really need to get it right now, otherwise we are going to be going back and correcting our mistakes in the next few years, just as we did on desktop and we don’t want to go down that route anymore.”

2. “Switch on the device Accessibility settings…”
It may sound obvious but “If you’re designing something and think, how is it going to work, you’ll get a sense quickly when you turn on the functionality as to whether or not it’s going to work. You can do it long before you come to user testing” (Robin Spinks).

3. Apply the K.I.S.S. (Keep it simple, stupid) philosophy

(i) Irritating features
Samantha pointed out that people with dyslexia and those with fine motor skills difficulties are not fans of lots of small buttons placed very close together. They are also put off by continuously having to set new passwords which demand to be cap sensitive, 8 letters long and incorporate a character “You think now I’ve gotta remember a new password! I can’t tell you how many apps I’ve binned… PayPal is fantastic because you can have a pin, a 4 digit number instead of a password.” For Paul “Not being able to tab between fields – incredibly irritating. And not being able to get the effing keyboard out of the way. It’s half the screen. Stop it!”

(ii) Do not discriminate between users
As Suzette advocated “In designing the apps, we want to think about people who are in the population, [disabled users] are not a special group… they have particular diverse needs. But actually, you know… what’s clean and simple is always good… The best interfaces you all use are probably also the cleanest and the simplest interface.”
Honestly, does it come as any surprise that the pet peeves identified by the panelists are also issues experienced by many a smartphone user? Once again, this points heavily to the importance of user testing across the board: test products with the very young, the old, those with disabilities and – well, just about everyone else in between!

4. Make it meaningful
Who doesn’t want apps that helps enhance a person’s life? Suzette gave an eye-opening example of an 82-year-old lady who could not get her head around how to use a computer and couldn’t see the value of using one. However “When she was introduced to Skype on the iPad, it was a completely different story. It was immediately obvious it was about her being able to talk to her granddaughter in Australia and about her being able to use something that had very, very few controls and she knew she couldn’t break it. Giving people a simple route that’s meaningful and touches their lives is a really important thing to think about.”

Customisation + Customisation = Accessibilty²

Samantha and Robin agreed that customisable apps were both helpful in terms of improving accessibility and, aside from any disability or need, surely a desirable feature for any app. Damon suggested that giving users a choice over which accessibility features to enable would also go some way to managing how developers, in lieu of any all-encompassing standards, build in greater Accessibility to their products. Robin proposed that customisation may also answer the question of how developers build in something that works for as many people as possible but has minimal cost implications “A device that can have as many different options… For example, being able to connect to a Braille display, or a Bluetooth keyboard, or a switch… It’s about all of that functionality actually being included and… the care being taken in the design and development stage to make that happen.”

Accessible products Make Good Business Sense

1. Expand your market, expand your sales:
(i) Apple and Accessibility
It’s also worth remembering that the the disability market is a very big market. It’s likely, as Damon suggests, that the more Accessible a product, the more people will buy it. Look at Apple. “In terms of consumer electronics they are the company who are pushing that harder across their product range” (Damon Rose).
(ii) Accessible products are moving into the mainstream
Another reason for why large companies like Apple are looking to create more Accessible products is, according to Damon, due to the rise in visibility of people with disabilities “They’re buying things online… becoming more embraced by commerce. In the US, the big store, Best Buy, was holding Accessibility dates and giving the entire store out to promoting Accessibility within devices they have in the store… That’s bringing the market out. It’s making it more visible.”
Robin confirmed this growing trend, recounting how “Even just to go back two years ago; we were running events, showing people how to use an iPhone… Fast forward two years to 2012, Apple are now chasing us, looking for us to run things in their store. The stuff about it being a specialist environment, it’s really moving into the mainstream. App developers are ringing us up saying can you help us to test apps, can you put us in touch with people with disabilities and other organisations that can test the apps to make them really, really easy to use.”

2. The Business Case for Inclusive Design and putting the user first.
Again, look at Apple “…who build in broader functionality and accessibility features at the design stage… There are others, for example, Panasonic have released their entire 2012 range of televisions which actually talk. It’s not an added feature; it’s something that’s been built into the specification” (Damon Rose). The excellent Inclusive Design Toolkit2 nicely talks through the commercial benefits of listening to users early on in the design process:
Every decision made during the design cycle can affect design inclusion and user satisfaction. Failure to correctly understand the users can result in products that exclude people unnecessarily and leave many more frustrated, leading to downstream problems, such as increased customer support requirements that can ultimately reduce commercial success. Conversely, successful implementation of inclusive design can result in a product that is functional, usable, desirable, and ultimately profitable.
(inclusivedesigntoolkit.com, 2011)

3. Enable your staff to do their job
The reduction in disability benefits means we are more likely to see people with diverse capabilities and needs entering the workforce. It therefore makes sense for companies to ensure that their software, mobile apps and devices are Accessible.

Paul Carter

Legislation Matters
In the UK, there is no specific legislation regarding Accessibility for mobile, whereas in the US, mobile handsets must, by law, be Accessible. Paul Carter added that as cost is a real obstacle, regulation is necessary to push further development in this area. He reminded us that:  “…We suffered for many years in terms of physical access to buildings, being told it can’t happen because it’s too expensive. It was only when that came into legislation that that actually changed.”
Alongside legislation, Robin encouraged organisations that represent groups of disabled users to mobilise and build alliances with international communities that can put forward the case for Accessibility. “It also means when you come to try and talk to Google, actually they want to entertain you. They want to take on board your concerns.”

Discovering the best apps for Accessibility
While AppleVis came up as a key source for VI Apple users, the panelists agreed that the primary means of discovery is by word of mouth. Paul explained that “There’s lots of communities in the disability world. If something is recommended, then it takes off pretty quickly. Most people hear about it.”
Also useful to know, when it comes to marketing your app, Robin talked about harnessing the power of Twitter “One thing that’s happening a lot in the VI sector is if an app becomes Accessible, then actually word spreads extremely fast around Twitter… There’s also a podcast called Access Talk. Robin summed up the discussion by saying that “Share is the keyword in terms of knowledge and updates and experiences.”
On a side note, Damon mentioned that he wouldn’t have bought his light detector app if it had been offered in the RNIB store rather than through iTunes. Am not sure if this is just a question of branding but Damon’s comment could suggest that apps created for a specific capability loss should nevertheless be made available on all the regular distributional channels.
Samantha confirmed that a large number of people in the dyslexic community use iTunes “…and they got very annoyed when apps weren’t available in that and they had to buy them directly off a website. It was confusing.”  The moral of the story? Check with your users! Ask them where they expect and prefer to find their apps made available. Again, this is good practice for all, whoever we’re designing for.

Product Doctor Diagnoses – OTA 2012

Alex Craxton visits the Product Doctor Surgery

Here’s the report from this year’s Product Doctor Drop in Surgery at OTA 2012.

Another interesting range of products; from making a good old phone call, through to tracking housekeeping budget, m-health to enhanced status posting and finishing with around the world travel.

From what I saw in the surgeries, a few trends were certainly coming through:

  • incorporation of scanning technology
  • the continued growth of products to support social networking status posting
  • m-health becoming a reality
  • increased adoption of value added mobile services by the corporate market
  • revenue models from businesses rather than individual spend

Diagnosis hinged around some familiar threads –

Tom Hume drops in to talk shop

1). End User Validation– making sure that user insights are gathered at concept phase and continued user testing continues. The point, as always, is that this is not just usability testing, but testing that the overall concept you have.  Identifying user need and desire, supporting revenue models and product feature set all need to be validated before you go and build your product.

2). Ensure it is a Genuine End User – friends, family, established business contacts and friendly existing customers do not count – they don’t want to upset you.  Remember also, that you are not representative of an entire segment – building something on your own needs is not validation.

Please see “DIY User Engagement” for more guidance.

Paul Moutray gets medical

3). Revenue Modelling – Really think hard about where the pots of money are; this year there was more talk about collecting and providing customer information to brands and generating sales leads for brands.  In this climate and market, a product really has to be amazing for an end user to want to pay for it.

4). Know your competition – make sure you understand who is vying for your customer money or attention.  Think hard about what you think you are selling and question whether it is already being provided today.

5). Just because you can, doesn’t mean you should. Technology brings many new opportunities and there are some very clever developers out there, but please check out the commercial bases before you give up your job and start building a new product.

There are a couple of other points that struck me this year. I thought about how useful it could be for my patients to hear each others session. Some have experience in areas that others have not and that “share” could have been helpful.  Tying this together with some feedback last year that this felt more like “product therapy”, I am wondering about running group surgeries next year…

Nail your Launch Strategy at an early stage!

Last week I mentored 13 start ups in 2 days at Start Up Weekend Education London (#swel) and at Ignite100, where Katrina and I ran a Product Doctor Drop In Surgery for the teams in Newcastle.  One of the consistent themes was that teams were not thinking about their Launch Strategy early enough. If you read the below, you will see how important it is to do so and how it needs to be considered during the Product Development phase rather than aftewards.

Diagnosis: Your product feels like all things to all people
This can be a dangerous position as it is difficult to focus in a way that enables you to understand who your end users are. This distance between the product and its end users is likely to result in feature overload, lack of clarity in the product description, product positioning and launch plan which will ultimately limit your success.

Feature overload increases your time to market. The more features, the longer the product development time, the longer the testing time is and the longer the fix period. It also adds time to future development time as regression testing takes longer.

Lack of clarity in the product description, product positioning and launch plan may not “speak” to end users in their language as you don’t know what language they speak. If they don’t feel targeted it will be more difficult to get them interested in your product.

Then the million dollar question: “How are you going to drive traffic to your site?” If you don’t know who you are targeting, how can you possibly work out how to drive traffic?  Of course everyone talks about the industry press and blogs – but will this reach your target group?

Be really good in one area first. Consider organising your product roadmap around product launches to different sectors / areas, each backed up with a tailored feature set.

Work closely with your end user target segment to not only establish the feature set but also develop ideas for product positioning and launch tactics.

For your initial launch, select an industry sector / area that you have some connection to already. Either you have worked within it, or you already have contacts who you can get close to, giving you access to end users to engage in the ways described above throughout the development process.

You can show your product feature list to users (worded in user-friendly language of course) and have them put the features in order of desirability. Ask them not to rate any features that they are not interested in.  You should see some consensus forming quickly as long as you have defined your target segment well. You can also get them to indicate where the features are a hygiene factor (they just must be there) vs something that feels it is different to the competition. Note that it is not who you think your competition is, but who your users think your competition is.

Cross tab this feature list against a scale of how easy / difficult the product is to deliver (Scrum processes involving points to show this is advised). Cross tab this further with some benchmarking and make sure that the sector / area you choose does not already have a popular solution. Ensure that you work with end users to establish where any competitors are strong and weak. Establish your product feature set and positioning around these insights.

For more tips on “DIY User Engagement”, see my previous blogpost.

DIY User Engagement

Me, Katrina Damianou and one of our patients: Ketan Majmudar at the Product Doctor Surgery, OTA 2011. Photo courtesy of the fabulous Paul Clarke - paulclarke.com

This year at Over the Air in Bletchley Park, Katrina and I set up a Product Doctor Drop in Surgery offering 25 minute complimentary sessions. On a scorching couple of days, we set up outside and were happy to have a continual stream of patients, including the wonderful @Documentally and @Bookmeister.

Listening carefully, as we always preach, we are considering next year calling it “Product Therapy” as the sessions seemed to have a cathartic effect!

Rather than blogging a long post, here are the contents and the full paper is available for download below.

  1. It is never too early (or too late) to engage end users
  2. What do you show users?
  3. How to find your end users
  4. Can you have the conversation with end users?
  5. How to begin the conversation
  6. Write a test script
  7. “I can’t explain what my product does”
  8. Showing a prototype
  9. Testing for usability
  10. Keep checking back with users as you develop and improve each new feature
  11. Build and test your product before developing your brand
  12. Be honest with yourself as to why you are developing the App
I hope you find this useful and as always, please do get in touch or leave comments below.

Just had an appointment with the Product Doctor

@Documentally aka Christian Payne aka Our Man Inside – our first happy customer at Over The Air Conference!  Key insight here was to consider who your users / addressable market think you are and what you do,  not who you think you are. His comments on Posterous are:

“…Massive thanks to @Jewl and @Katzstar for giving me therapy. The things I didn’t know about what it is I do & how I could do it better…”

Dr Katrina listens for signs of life!


“Just because you can doesn’t mean you should”

A few months ago, I was talking to a friend about his new B2B product which was in the process of being prototyped.  The words that tripped out were “Just because you can doesn’t mean you should”.

The product was being centred around insights gathered by the CEO through general conversations with potential end users.  My concerns with this were:

  • The potential end users were not budget holders and therefore could not eventually make the decision to purchase the new product.  So in this case, research around the benefits of the product should be also carried out with budget holders – seeing if there is a case to make their organisation more efficient / productive / profitable as a result of adopting this product.
  • The potential end users had genuine pain points that needed solutions, but the prototype was a number of months down the line and no one had been back to those potential end users to see if the solution being developed was addressing their need. As I always say, you don’t need to wait for a prototype to continue your dialogue with users. You can talk about what they would want the product do to and why – build up the bank of “user stories” (Scrum reference) and get those prioritised before you begin your build.
  • The CEO may well not be the best person to talk to end users. Classically CEOs are strong characters; leaders who are passionate about their product.  An end user may well not be comfortable to say “no” to a person like this!  It takes certain personality traits and practice to be good at gathering user insight.

The very talented developer was building up the prototype from sketchy top line requirements written by the CEO. He was injecting a large dose of filling in the many blanks with clever code that enabled the product to do all sorts of things that had never been done before.  But was this functionality that the user wanted and the budget holders would agree to buy? Nobody knew.

Diving in to the feasibility (technical capability), working up the viability (scale-ability) and then establishing desirability (the user need) is the trap.  This is how many companies end up with a product that may technically work well but does hit the sweet spot with users.  They then often then find that they are continually customising the product for individual clients, which is not cost effective and not scale-able.  Another classic result of this approach is feature overload – features built in to a product that are never used – again resulting in wasted resource.  This model needs to be reversed and you need to start first with desirability.

Point made?!