Women can’t do things that men do

…, or says stock imagery sites.

Since becoming a Senior Instructional Designer we’ve worked exceptionally hard to make sure our modules appear to the represent the global audience that learns with us.

However often when we’re trying to make our pages more appealing, we have to turn to image libraries to help us either make a point, or to just make the page more appealing, so we turn to stock photos.

This sounds fine until you begin to realise that certain stock libraries may only show a particular reflection of life to you. Please try the following searches out, on your stock library, we’re using Adobe stock for today as it’s easy to use and often the most forgiving when adding in extra keywords.

(P.s., for the woke people of the world, this will frustrate, I promise)

Try searching for sailor… then sailor woman.. what did you notice?

Did one show more flesh and one show more authoritative figure? Obviously the call for sailor imagery in our modules is pretty low, however I hope it highlights the underlying bent of the image searches we make.

A screenshot of the search, “sailor woman” from pixabay

Search for business deal… what did you notice?

Any particular skin colours showing more than others? Any particular sex more than others?

Finally, try searching for muslim government, what do you see?

Why the mix of pictures relating to government, then why guns and refugees being turned away?

What about the related keywords from when you search for, “muslim government” in pixabay? (2019, May 5th – this was added)

Muslim government search shows, “Riot Violence Revolution Unrest Protest”

Christian government related search shows, “Cross Jesus Church Catholic Government”

Our team works very hard to show a positive reflection of a global society and of our learners. To make that happen with a stock photos system that may show a rather different reflection to what we want, our searches add on other keywords to help us break free from a particular, stereotypes and tropes.

Please see below how we alter our work by adding in some frankly blunt keywords,

  • Stock photo choices should majorly attempt to prioritise photos of women. That is not always possible, but if we push for it normally, the balance of sex and genders will be more properly represented.
    • Try adding, “woman”, “clothed”, “success”
  • Stock photo choices should majorly attempt to prioritise, or include someone (or a group) who is not white skinned. That is not always possible, but if we push for it normally, the balance of skin colours will be more properly represented across a whole module,
    • Try adding these keywords, “mixed race”, “black”, “turban”
  • Stock photo choices should look to actively  include, and possibly re-hash imagery to positively include muslims. People actively taking part in the activity other than violence or shopping
    • Try adding, “Niqābs business”, “Thobe deal”, “muslim business”, “muslim woman business”

Obviously this is a larger discussion than I’ve covered above, but I hope it shows how we are actively doing our best to use positive imagery in all our global modules.

btw. Most of this post was written a while ago and stock photo libraries change over time, so the searches may hopefully prove the above wrong…

We’re ignoring our stakeholders and they couldn’t be happier!

The following is a set of techniques that at WMG, Warwick University I have led and implemented on various digital projects to great success. Stakeholders are happy with it, and they’re not inadvertently altering the success chance of the projects.

You’ll recognise this. Every project you run, has a plethora of stakeholders involved. In some large organisations too, you’ll find they enjoy a rather flat structure where everyone’s opinion is valid and should be considered.

So when you invite lots of people to a meeting, you come out with a mess of features and a confusing array of project actions which possibly didn’t need chasing up. Because of this we need a framework that will allow for ideas from all people, but only qualify the ones which are “goers”.

Here’s 4 tips that I use with my teams at WMG to both keep the stakeholders happy. It makes but the project the most important success factor, not egos. It makes everyone nearly equal.

1. Have a shared Product Backlog or the “the duff idea buffer”

This is a place where all ideas are held and are accessible to every stakeholder. This isn’t an obtuse Word Document you keep emailing round with “Track changes on” and forgetting to CC (Carbon Copy) people in, but more like a shared pinboard on Trello.com which you can export every so often to Excel.

The reason for having a shared Product Backlog is more to do with human behaviour than anything else. Often in a working group of many, you’ll find most of the angst is whether or not someone’s personal idea was set down and recorded. Some / most of the suggestions will be pants, off-topic and not worth the keystrokes you took to record it, that’s natural, we all do it.

However, if it’s fairly recorded somewhere you can move on, rather than discussing its use-fullness there and then.

Often you’ll find that the person who raised it, after a couple of days, gets some perspective and realises they don’t think the idea’s any good anymore.

1. Have a Product Owner (the gatekeeper)

This is 1 person. Not two, three or 12. Just 1. It is 1 person who was voted by the stakeholders as the “best decision maker for the project” and who always decides what’s the most important action for the project next.

So sure, the stakeholders have now had their thoughts recorded into the backlog, but let’s be honest, quite a lot of that might not be immediately urgent or produce the highest business value. So a Product Owner is voted in by the stakeholders as the person best placed for making decisions on the product.

They have authority. They were voted in by their peers, and so can yay or ney actions confidently. Also, if you’re worried about someone being voted in that’s a bit power hungry, it’s good to know that this role has a lot of responsibility, so their decisions have to be good, they’re picking how the project progresses.

3. Be strict.

Yup. They’ll hate this bit, but you need to vote in someone who can stick to these rules and keep to the rhetoric of, “Great idea, put it in the Backlog”, “You don’t get to pick, it’s the Product Owner’s choice”.

This way, no stakeholders can adjust how the project goes as they agree to the rules of the Product Owner says what’s next. By staying strict it helps fight the “culture eats process for breakfast” saying and starts adjusting how you work together.

4. Keep everyone updated, frequently

Every 2 weeks, re-present to the stakeholders what’s done so far. Then chat about what they think is important next. Invite them all every time, and after a while you’ll see they more just want to leave you to your work and don’t turn up. Allowing the process to move on.

The Product Owner can then make the decisions based on feedback about what’s next.

I hope that helps!

Note…. In the title, I mean, “happier” with our process, I imagine their first child or standing on a surfboard might also be a happy event.


Being brave enough to change a process

Today we had to change a large process that wasn’t working.

The State.

A web development being built hasn’t got automated tests written for it and requires an office member to go through and MANUALLY test every item. Basically what Behat or DalekJS should be doing…

Anyway, the tests were all written in 1 document. “When I create a module, it should appear in a student’s list”, “When I select 3 modules, it calculates the student’s points correctly”, etc…

My process to solving a process.

Sometimes improving it can feel a bit daunting, however, as you talk through it with the team, record small sticking points and pains, then the you should start to see a bigger picture.
Always remember, you probably just need an evolution not a total revolution.


  1. Remind the team, that they own this process so they will want to find solutions to save themselves time
  2. Talk through the whole process, record EVERY sticking point
  3. Look through the sticking points for the worst offenders
  4. Think of simple ideas to fix them
  5. Repeat 4 until happy 🙂
  6. Talk it through with all the team
  7. Go!
  8. Re-look at it again soon!

Our Biggest Problems were…

  • Testing document, who has the latest copy and where?
  • TheTesting document is really fiddly for comments
  • TheTesting document doesn’t really handle versions very well
  • It’s difficult to discuss the comments inside theTesting document
  • What should the developer work on next?

Some solutions…

  • Testing document has been moved to a Shared OneDrive for all the project Team.
  • Re-named testing document “Testing Document v1” to “Testing Document”, losing the version number indicated its “alive” state
  • All Passes are still recorded in the Testing document with the word “Pass”
  • All Fails are recorded int he Testing document as “Fail”, but no comment
  • All Fails with comments are created as tickets in a Trello board with the unique test id and a description of the fail
  • All Fails are re-ordered in the list by the Product Owner to show importance
  • A Trello list was created for the Product Owner to rack up no more than 5 tickets which the need the developer to work on next

Should you allow clients into your bug tracking software?

I believe yes, you should. With the proper caveats and training, your client should be able to see what’s going on.

The client has fewer surprises, is in on the problems and #FTW’s. They feel more connected to the product and weirdly will start to feel more “onside”.

Sure it might seem scary at first, but after the initial storming, the process does begin forming!

It’s all about improving process through transparency.