,

Towards sustainable AI: The Data Science development process

Elemental Concept Blog - Ghislain Landry Tsafack

Towards sustainable AI: The Data Science development process
Whilst generally organisation specific, typical data science processes involve the following keys phases: business understanding, data collection, model building, evaluation, and deployment. The “performance metrics” phase introduced here provides a template to the integration of business requirements.
Although performance measurement is generally performed as part of evaluation, it often fails to integrate business requirements not directly related to the AI system’s accuracy. For example, an AI recruitment system satisfying traditional performance metrics may fail to meet an organisations prioritised objectives, such as avoiding gender bias. We refer to such objectives as “soft performance” metrics.
Defining performance metrics as an additional phase allows the business and the AI team to agree on the objectives of the project. Non-functional requirements and expected behaviour of the system are identified and documented, leaving the development team with clear objectives. Based on this, the development team can design a system that meets the organisation’s expectations. It may also result in a project being deemed infeasible, given its dependence on data consistent with these objectives.

#sustainableai #aiprocesses

null

/by Ghislain Landry Tsafack

Data driven testing with Spock and JUnit5: Who wins?

I’d been a Java developer for some years when in my previous company we started using Groovy and a testing framework “that makes things easier to test” as my more experienced peers used to tell me. If you’re familiar with Groovy, then you know what the advantages are in terms of streams, lists, maps, closures, getters/setters out of the box via reflection (there goes privacy), etc. Some companies will use Groovy for their main development and tests or other will use it only for the latter, in terms of setting up easily test methods, helper functions, no builders needed, etc. Like you’d do with Kotlin.

Though this article is not here to discuss whether Groovy wins or loses as compared to Java, the former can be combined as the language means to a very powerful testing framework (and my favourite one), Spock. For an introduction and how you can use it, please visit the official documentation page and an Introduction to Testing with Spock and Groovy.

When I started to write tests in Spock, I was amazed with how easy it is to set up and write a paramerized test, i.e. one test or one template if you will, where you specify varying inputs in a multiline block. E.g.

import spock.lang.Specification
import spock.lang.Unrollclass MathTest extends Specification {  @Unroll
  def "sum of #a and #b equals #expectedResult"() {
    
    when:
    def actualResult = a + b    then:
    expectedResult == actualResult    where:
    a | b | expectedResult
    0 | 0 | 0
    0 | 1 | 1
    1 | 2 | 3
  }}

For more information, please visit Data Driven Testing section of Spock documentation.

In Junit5, you can do the same, albeit not that easily. Let’s see how it goes:

You replace @Test, with @ParameterizedTest. This annotation is a successor of Junit4 annotation: @RunWith(Parameterized.class)

class MathTest {  @ParameterizedTest
  @CsvFileSource(resources = "numbers.csv", numLinesToSkip = 1)
  void testsForSum(int a, int b, int expectedResult) {
    assertEquals(expectedResult, Math.addExact(a, b));
  }}

OR:

class MathTest {  @ParameterizedTest
  @MethodSource("populateIntegers")
  void testsForSum_2(int a, int b, int expectedResult) {
    assertEquals(expectedResult, Math.addExact(a, b));
  }  private static Stream<Arguments> populateIntegers() {
    return Stream.of(
      Arguments.of(0, 0, 0),
      Arguments.of(0, 1, 1),
      Arguments.of(1, 2, 3));
  }}

where numbers.csv is:

a,b,expected
0,0,0
0,1,1
1,2,3

For more info, please visit a comprehensive Guide to JUnit 5 Parameterized Tests  and Using JUnit 5 with Gradle.

In terms of lines or difficulty, JUnit5 seems to be really intuitive (if you get the gist of naming and basic building blocks for parameterised tests).

The complexity is increased when we want to test more complicated varying use cases.

In Spock, the “where” block is easier to construct. It can even take methods as parameters as long as they’re static.

JUnit 5 vs. Spock feature showdown offers a more exhaustive comparison.

Finally, please visit playground and playground-junit GitHub repositories that investigate the same use case scenario, using Groovy/Spock and Java/JUnit5 respectively. Both repos have the same Colour class, playground one has a Groovy/Spock based ColourTest class, while playground-junit has a Java/JUnit5 based ColourTest class. They follow almost identical test cases in order to be able to show and compare the logical flow and different syntax when writing data driven tests.

/by Maria Michou

Explainer video script? No problem

I find some of my best work comes from tight situations. This has proven true throughout my various jobs around London and definitely in my capacity as an Art Director back in Ireland. There is a mad rush about the sudden, unforeseen situations that spark the fight or flight flame in all of us and in the creative field, sometimes you need to step up to be the MacGyver that’s needed and with only your wiles (and maybe a scrap of paper and a paperclip) know your end goal and drive the work to where it needs to go.

This article is basically the summary of a particularly effective business development conversation that we had in Elemental Concept over a year ago. And as all the best stories come from tight situations, we all know this started with the most ideal working conditions, right? Not really…

The challenge

A client walks in, saying that they need to get a video out within the week to be able to pitch in front of an incredibly influential group of investors, all the stars have aligned, their time is now, etc. And all the only other small thing they need (I can hear the designers shaking their heads in the back as I type…) is a simple, animated explainer video.

There was no script. No existing messaging. And the client had only half an hour of his time to give before he had to leave…

“There is no point in having sharp images when you’ve fuzzy ideas.”
Jean-Luc Godard

Panic Stations?

Now instinct would be to panic, but what a challenge to step up to here. What better scenario to breathe, take the opportunity to roll the sleeves up and face the situation head on and drill our client until we got what we needed.

My art director roots in film and TV was to come back into play, in tandem with the UX challenge of shaping a message that would engage the user’s motivations in the right way to get them to engage. I was extremely lucky in having a fantastic motion graphics designer in Leigh Williamson so I was confident in his ability to knock out an animation within the crazy timeframe. But we needed a script, we needed a story.

And so this simple script generation template was born. From that half an hour of frenzied typing and questioning, came this lovely simple resource that’s proved itself useful over and over and over again. At the end of the day, we love a structure and when it comes to a story we can digest, there’s no more straightforward way than this.

No experience in script-writing needed

You need no experience in writing or scripting to do this – Just an understanding of your client’s business and the right questions to ask to fill out our 4 paragraph script template which will help you translate your client’s business model summary and elevator pitch into a succinct and compelling story that drives engagement. Let’s get into it…

The 4 Paragraph Script Generation Template

The 4 Paragraph Script Generation Template

Paragraph One: Frame the problem

Provide a brief intro to the issue we wish to solve, (whether general or using a particular use-case), all the parties it negatively affects, the impact on X, Y and Z and why it needs to be solved, etc.

Paragraph Two: Frame the solution

Name our solution and how it works to directly answer our problem. What inspired it and what its mission/desired impact is, etc.

Paragraph Three: Sell them on the benefits

List all the benefits of using this solution, particularly referencing issues named in paragraph one or in the established use-case, etc.

Paragraph Four: Summarise the story and main takeaways

Recollect the original issue, how this solution works using X, Y and Z to ensure not only are your problems solved but you’ve provided a good experience, happy customers and other benefits, like scalable offering, modern tech, etc.

Bear in mind, the last statement should always focus back to the name of company, logo and product, using a snappy tagline or a sentence summing up why it’s the future, why it’s the default choice, etc.
End with a bang.

Next steps

So, you have your fact finding template, successfully distilled the necessary content from the client – What next? We need to start polishing creating a narrative and polishing these bare bones into a fully fleshed script.
Things to be mindful of:

  • Make sure you’re telling a story
    This template enables you to establish the bare bones that will shape your story, but it’s up to you to ensure there’s a flow and a strong narrative sense to all the information. Get your first draft shaped and send out to your client to ensure message is captured correctly and iterate from there.
  • Keep your brand voice in mind
    The content in your video expresses the ‘voice’ of your company or brand, so it’s good to be mindful of the type of voice you want to have. It works in concert with your whole visual and digital presence, your social media connections, your product interface, and your event and experience branding.
  • Get to the point quickly
    Remember your user. UX 101: What is the message you want the user to get out of this? Get this out there as soon as possible and don’t allow the core message to get lost in details.
  • Read the script aloud
    This is not a document, this is a living script that needs to be read, that needs to flow off the tongue and resonate in an auditory way, as well as inspire visuals to go alongside it. Reading your words aloud is essential to finding stumbling blocks in the text, seeing where you need to cut sentences that are too long and editing from there.
  • Keep it short
    Wistia’s research tells us that on average, they would track a 5% difference in the length a user would watch. For example, a viewer would watch 42 seconds of a 60 second video, 78 seconds of a 120 second video. So, in conclusion, the longer your video is, the more content your viewers are going to miss out on. Make as many revisions and edits as possible to keep it clear, concise and snappy.

The happy end to the tale was that we successfully delivered to our deadline and in the process, created an asset that has continued to save time, provide great value and solid structure to how we shape and define stories for our clients.

“Once you crack the script, everything else follows.”
Ridley Scott

Nailing the explainer script has the benefit of laying the foundations for website and pitch-deck content, as well as really defining the voice and identity of an emerging brand or product.

Lack of experience is irrelevant – That’s the beauty of the template. It does your thinking for you, frames the key questions to put to the client and lays the groundwork for success. Like any mountain that seems impossible to climb, it’s not a question of being unsurmountable.
It’s simply a question of knowing where to start.

/by Róisín O'Toole

Choosing Wallets: What to look for?

Elemental Concept Blog - Alok Ashtikar

Continue reading on Tech Take…

/by Alok Ashtikar

Digital Distractions

As a team at Elemental Concept we have years of experience at helping organisations innovate, scale and transform. Over those years we have created a proven methodology to help companies embrace technology. We help them understand how to enhance their business models and to differentiate themselves by using or building tools that help them better solve the customer problems that created their business in the first place. That is the core of what we do, ‘the Elemental Concept’ – so whats happening in the world now should be great but its actually surprising.

Since we got involved in the technology consultancy business there has been a paradigm shift. Everyone has charged down the technological path and now the whole world not only seems to demand a digital transformation but also needs to be(come?) a technology company. This uncontrolled rampage towards digital is insane, as I will explain, but what’s even weirder is that we at Elemental now find ourselves in a place where we are trying to stop the profligate spending on tech because there is so much waste.

You’d think that I should enjoy this waste- I mean what kind of nutty CEO of a technology consultancy doesn’t like customers spending wads of money on tech – but its not in our business model to make money when we aren’t creating value for our customers. I realise that this might seem the intro to some kind of sermon, but I just want to share some observations with the outside world so that you can tell me if you think I’m going mad.

Digital Transformation

Those two words used to irritate me as they seemed to symbolise everything wrong with what was becoming the new vogue: to cloak a business in a miasma of how it did its business digitally rather than why it used the new tech or what the tech (or business) did to add value.. It is true that there are huge benefits to businesses in using digital tools to engage with their customers, improve processes and better understand their resources, risks and opportunities. However, if you analyse the history of technology spend you will find a trail littered with the corpses of failed transformation projects (and defunct companies as a result).

In the early days (take e-borders as an example) they used to attribute failure to the waterfall style of implementation. There are definitely many things wrong with waterfall; you spend too long over -specifying a system, creating a price war and then implementing something that by the time it’s ready it is out of date (you still see this in big company procurement processes). The problem is that people don’t seem to look at the underlying reasons for the failures and keep blundering along.

What agile did as an implementation philosophy is bring in a way of coping with continuous change. By delivering things in small cycles where you test, learn and iterate so you can keep pace with the speed that technology and users’ behaviour changes.

All this learning seems to have been forgotten in the digital transformation gold rush. Instead of small iterative changes we are seeing large scale implementations that may take years to build, will still be out of date and are going to cost a lot of money.

There seems to be an abnormal focus on the word digital in these programmes, in our sprint (sic) to embrace apps, big data, blockchain and AI we seem to have forgotten that transformation is bigger in terms of impact to people, processes and most of all customers. A company may build the best system in the world but if they don’t train and reskill their team, change their processes and educate their customers the whole digital effort will be a disaster as they forgot that it wasn’t the technology that was transforming: it was the company.

The other thing to think about is that we shouldn’t get obsessed with the word transformation. Why aren’t we learning from the big failures and implementing a business strategy more. What’s wrong with evolution? If we think about evolution we might think about smaller iterative changes that carry the people, processes and customers at the same time.

So in reality we need to keep our feet on the ground. Or perhaps, one foot on the ground as that’s the whole essence of a pivot rather than a leap or entrenchment. There are some unbelievable advancements that technology can bring to a business but it is the business and all it consists of that is likely to require the evolution.

We are all technology companies

If you look at the stock market there are a number of companies that are classified as a technology company and you have to ask yourself whether they are really a tech company or simply using technology to deliver their business model.

Examples that spring to my mind – AirBnB (it’s really a house letting business), eBay (its an auction and marketplace), UBER (it’s a logistics play). I know I’m doing them a disservice as like Amazon they have ventured beyond the core strategy they started with, and in order to do this have moved closer to being a ‘tech company’. There are however some fundamental principles that make me think these are not technology companies. AirBnB make money from allowing people to let homes, if there are no homes advertised they make no money regardless of how great their matching engine is. Uber needs drivers and people who want to use them. Without them that beautiful user interface is pointless. So I’m sure you get my argument these are traditional businesses – holiday lettings, taxis, food delivery, auctions aren’t new- it’s just some people were smart enough to use technology to deliver their business model. This doesn’t make them a technology company.

There are companies that have evolved. Transformed even. Amazon went from being a bookshop to a provider of cloud services. Ocado went from being a grocery store to also a provider of technology for online grocery stores. It’s really only at this point in their evolution where they are actually executing a business model that sells tech that in my mind can they be classified as a tech company.

So why are we obsessed with calling these companies tech companies? Part of it is simply history.The dot com bubble in the late nineties was led by the innovators who wanted to revolutionise every business by taking them to the internet. All of those companies were classified as tech stocks. The investors that picked well made a lot of money as these companies succeeded as they essentially tapped in to a new, more effective and cheaper distribution model. These investors were tech investors – ones that had quite often taken a bet on (or had recently cashed out their options in) the higher-risk, actual technology companies, like Apple.

The few successes out of the dotcom era spawned a new wave. They were executing traditional business models but using tech to give themselves greater potential. This meant they were valued higher. And that in itself has led to the classification problem I see today.

All businesses now want to be classified as tech companies because in theory they are worth more. This is nuts, soon every company will be classified as a tech company because natural progression means each and every industry will use digital technology more and more.

We have the priviledge of working with Prudential on one of their game-changing initiatives. There is definitely a large element of digital but it doesn’t make them a tech company as that forgets all the other key pillars such as product, pricing, sales, operations and reinsurance.

So let’s end the madness

Returning to my problem with every company being called a tech company, in reality I don’t have one – its more about the herd’s obsession to be seen as one. Much like digital transformation there is maybe too much focus on being a tech company and appearing digital. Too much time will be spent on talking AI, Blockchain and UI when its really the business model and its total delivery that should be focussed on.

In summary I don’t want my dentist worrying about his tech stack, or call himself the digital dentist. I want him to look at my teeth. If he wants he can bring in someone like Elemental Concept to help him understand whether technology can enhance his business, work out whether it would be worth the investment and then help him enable his digital evolution.

/by Bimal Shah

The persuasive powers of UX Writing

I see a lot of beautiful mockups and concepts online, whether it be Dribbble, Behance that try to sell people on beautiful UI, filled with Lorem Ipsum. And yes, it gives the illusion; yes, superficially, it paints a visual picture, but if you want a picture, go to an artist.

We are UX designers, we are supposed to be not only be bringing an interface to life, but an experience.

Our words are a critical tool in our arsenal that differentiate us from the herd and this skill is finally being appreciated as a powerhouse of its own right.

Words are the means of users successfully navigating a product as well as defining it. We may laugh but as simple as it may seem, the word on the call to action button is more important than its container. Beautiful UI may be one thing but the text that sets the context for the proceeding user journey establishes how comfortable a user feels from the beginning; the copy throughout your products has the power to delight or confound and frustrate people. And ultimately, make or break your offering.

“Words are singularly the most powerful force available to humanity. …Words have energy and power with the ability to help, to heal, to hinder, to hurt, to harm, to humiliate and to humble.”
Yehuda Berg

So for me, there’s always time for a good word.

I have always been a writer.
My attic floors strain under the pressure of over 50 diaries spanning from the age of 6. They’re accompanied by boxes upon boxes, filled with all manner of stories, poems, songs and plays, as well as a thousand scribbled notes of ideas on restaurant and hotel napkins. I was obsessed with words and the power they had to evoke passion and feeling.

At a young age, I was already highly aware of the impact a well phrased concept could have, as well as the different note you could strike with the same concept in a different approach.

Recognising the power of voice and tone

I have very lucid memories of my first experiences of news writing in secondary school English class, where at the age of 13, we learned the differences between sensationalism and fact driven prose, ultimately leading to amazing exercises in creating scandalous tabloid articles as well as stiff upper-lipped broadsheet reporting.

At this point, I was already appreciating tone of voice, brand and identity in words without realising it. I was already starting to associate values to the words coming from specific voices and most importantly of all, I recognised the necessity to stay true to these voices, to remain consistent if you were to make a piece meaningful.

It was a simple exercise but a resonating lesson.
I’d like to think Ms. Whelan back in Taylor’s Hill would be proud.

More and more, I am grateful for my love of words and love for writing because it serves me on a daily basis, when I am supporting my clients and my users through my designs.

At the end of the day, an incredibly important part of the user experience are the words that talk us through.

Can you create a decent walkthrough of a user journey for a client with Lorem Ipsum? I’m not sure. I’ll tell you why.

We’re the bridge between the client’s core concept and the user they’re trying to reach. Language plays a massive part in this. How we invite them to engage, how we congratulate them on completion, how we comfort them when they can’t achieve their goal – As much as real people talk, encourage, cajole and comfort each other in different ways, our copy, our word choice distinguishes the voice of that concept, the ‘character’ of that product and these characters can be remarkably different. They have to be if we want them to resonate with our users. Empathy is our greatest ally here – Know your users, know your character and talk to them appropriately.

This ability to write from an empathetic place is only going to become a more sought after skill with the rise of Voice UI and the need to communicate the way only through words, as well as massively so with Chatbot design and AI technology. Moses Kim, UX writer and researcher puts it perfectly when he writes:

Designing logic means operating psychology.

You need to actively do the deeper dive into the personas you’re dealing with and their needs, behaviours and habits and speak to them directly. The needs for those select words to not only be on point and hit home, in terms of usability and message but also in the part they play in the illusion that you are communicating with someone real on the other side.

Writing in the Rise of the Voice User Interface (VUI)

I remember this need for more character becoming increasingly clearer in the early naughties, when I felt the shift to the language I was coming across on applications and software moving from “Enter” to a way too familiar “Right on, let’s do it!” You might say a leap too far.

I appreciated the move towards a more humanised approach but at the same time, I felt “Well it’s talking to all the enthusiastic 17 year old surfer kids in the room, but maybe not necessarily to me…”

Propel forward a few years and we seem to have gotten the balance right, writing for language that’s accessible, conversational and relatable, which is exactly what’s required in the advent of Alexa and similar voice controlled devices hitting the world stage.

VUI is an incredible new challenge and one that is definitely worth brushing up those word-smithing skills for. Not only do we as designers have to understand the power of hitting our messages effectively but now that we’re actively writing scripts for people to vocally interact with and building elaborate user journeys based solely on dialogue, user empathy and clarity of message is more critical than ever, as well as a refined brand voice and intent.

First there was the word… The winning factor in a pitch

To return to the crux of this article, to me, the copy sells the concept. From a business development point of view, I believe the language is critical to win over the client. When we pitch for work and the delivery demands me to create accompanying visuals, as well as when we create and test prototypes with end users, the following five things in my mind are undebatable:

  1. There is absolutely no Lorem Ipsum on the visuals
    Even if I have to guess (and there is no excuse, if we were paying attention, for not making fairly well informed guesses), I will populate that UI with something that is relevant to that client and speaks to what they have explained to me. Even if we get it wrong at this point, we are creating the first draft that starts the conversation and pushes things in the right direction.
  2. There will be a distinct voice in the language
    I will always try, in initial meetings, to ascertain who the brand voice is:
    It’s as important from a marketing point of view as a user persona from a UX point of view. We need to know if they were a person, what would they sound like, who would they be, what would their back story be, who they’re trying to appeal to and why. It may sound trite, but it actually goes a long way in enabling me to imagine how they’d come across in the different scenarios they’ll guide people through in the user journeys I craft and ultimately, my understanding of this voice lights the way for me to figure out these journeys quicker.
  3. The words will be few and meaningful.
    I understand from my love of words, reading and poetry especially, that the key is in right words as opposed to a lot of verbiage that doesn’t cut to the chase soon enough.
    A haiku is powerful because its structure requires you to hit a concept in few words – Apply this type of approach to your copy, get to know your writing style and where you tend to waffle and cut, cut, cut. Bombarding a user with too much information at the wrong points is as much of a UX fail as forgetting the onboard – You risk overwhelming them and you also risk immediate drop off through boredom. Voltaire once said “The secret of being boring is to say everything.”
    The man knew his UX.
  4. My copy has already been pre-tested.
    Practise what you preach – Put your designs out for feedback and have the testers pay specific attention to the words. This is a brilliant tool for testing in general, as you generally have users fixated on design and at times, not even taking in the copy that’s in your beautiful UI.
    You want to know what they take away from a page. Having looked at a page for 10 seconds, can they tell you what functionality was available from it? What did the copy make them feel? Nothing? Assured? Condescended to? You never know until you ask.
    Asking questions about this very specific element will open up amazing new avenues for feedback and really allow you to gauge the effectiveness of what you’re writing and the resonating impression your product leaves on the user.
  5. My work priorities are on full display to my client.
    The effort and time it takes to write meaningful copy tells the client an awful lot about me: My depth of understanding of what they’ve taken time to communicate. My dedication to quality and getting to the next stage of the game, but more so than anything else, the level of detail I will go to to reflect their concept back properly — This is our gift. When it comes to selling a concept, this is where we bring the magic that can make a client say yes and an investor invest.

Practice makes perfect

“You can always edit a bad page. You can’t edit a blank page.”
Jodi Picoult

UX writing is a skill. And like any skill, you need to practice. Which is why instead of recommending you do courses, or masterclasses, what I’d say is simply do it. Start with filling out your Lorem Ipsum and go from there. Drive your progress by challenging yourself with different writing exercises to hone your skills – plenty linked below. Take the opportunity to put yourself forward to write presentation content, proposals, business development reports — take an active role in your own self development and wait and see how this serves you long term.

Watch as your time gets higher in demand in your company, as the amount of contribution you can provide grows. Watch how your user journeys come to life significantly more than before, as you sell a more compelling and complete experience. Watch how your designs get PO-ed more efficiently because your “clarifying text” actually clarifies.

Take the opportunities you can, ask your team to review your writing and more importantly, YOU review your writing. Learning how to self edit, knowing what’s superfluous and when to cut is another string to your bow that will make you invaluable, both in your UX capacity, as well as more generally to your company.

At the end of the day, you are the conduit for your client to get their product to resonate in the minds and behaviours of the users. So take that mantle with pride and remember that the words you design around will be just as instrumental to achieving your goals.

Remember your title and remember your gift.

The visual will bring you to the table.
The experience will make them sign the dotted line.

Thanks so much for reading. If you enjoyed this, here are some great articles that are well worth a read to keep you inspired:

/by Róisín O’Toole

Build or buy your Software?

Bespoke v COTS (Commercial Off-the-Shelf)) – What’s best for me?

The sad history of failure in bespoke development projects

The world of custom/bespoke software development is littered with failed projects, costs that over-run so much that the original budget is long forgotten and so the world of business lives in fear of the words ‘bespoke development’. Whilst it is clearly true that there are many high profile examples of bespoke development projects going badly (just look at the government sector and their travails with electronic patient records systems etc.), the fact is that, for many of these projects, budgets were well and truly busted, projects cancelled and investments written off, are the same as for many seemingly lower-risk failed ‘out-of-the-box’ COTS software based projects.

The truth is that it’s nothing to do with the ‘bespoke’ part of the project – COTS (Commercial Off-The-Shelf) has the same risks

It’s a sad fact that, over the 30+ years’ experience I have in the software industry, every single customer I have met who tried to deploy a certain ERP vendors ‘package software’ (name not supplied as I’m sure they have a large legal budget), has ended up costing the customer 4-5 times the original budget (and when it started with a budget of £10’s of millions in the first place – these are telephone directory like budget over-runs). However, somehow, COTS projects are sold on the basis of their being lower risk than a bespoke build.

In my experience the reasons for failure often have some common themes, whether bespoke or product, with the following being a summary of the leading contenders for ‘things to do to make sure your project fails’:

1. The customer and the supplier don’t have a good enough handle on the scope, but insist on the supplier committing to the exact scope of the final deliverable too early in the project cycle, resulting in shaky foundations and an, almost inevitable ‘you said, he said’ recriminations. Suppliers can also be guilty of getting carried away with the enthusiasm of a new project and take a ‘flyer’ on too little detail in their desperation to get the project started.

2. The customer business sponsor cannot get the buy-in from all of the levels needed to ensure a successful roll-out, whether this is at senior management level (where execs have to make sure everyone in the company understands that this is happening, why it’s needed and that it’s critical that everyone is engaged and adapts, as needed to play their part in making it a success), or at end-users level, where change is resisted based on ‘we’ve always done it xxxx way’. Software projects fail when the new software cuts across established working practices leading to user resentment and ultimately rejection; COTS as a one size fists all solution is inherently this; there is no scope to tailor; or if there is scope to tailor then tailoring will always be restricted and will lead to cost increases in the short-term and upgrade nightmares in the medium/long-term.

3. Scope is allowed to get out of control during the build in an effort to bring on-board all of the people not on board with point 2, resulting in functions being developed that are ultimately little used, or make the system/process overly complex.

No alt text provided for this image

As mentioned above, unless you have managed to deploy a software package in a completely vanilla manner i.e. there is no bespoke/custom functionality and even configuration options are kept as close to vanilla as possible, then the 3 points above are issues for both bespoke and COTS. If the right controls and even project culture are deployed, then a successful project can be guaranteed and so the choice comes down to:

1. Is there a COTS solution that exactly meets my requirements, is within my budget (both now and as my company grows, acquires, allows me to modify to suit future organisational changes and allows me some level of certainty around projected costs in these scenarios)? Sometimes COTS looks financially compelling, until you look at the long-term cost of annual maintenance increases, having to upgrade every xxx months/years and the risk that the supplier will decide that, at short-notice, your core application is no longer strategic and so being sent into ‘retirement’.

2. Do you believe that your requirement is unique and /or the marketplace not wide enough to ensure that a COTS solution will be available, or the competition/choice too limited to ensure the cost will be competitive and solution maintained and developed to meet new compliance or fundamental market changes?

3. Do you believer that retaining the Intellectual Property in the system would be beneficial to you and a differentiator in your marketplace? Do you want a software package that defines and controls the how people do their day to day tasks – or do you want the expertise and experience of you employees to inform and define the software that you build?

Managing Risk – Take Small Incremental Steps?

No alt text provided for this image

I’ve worked across both software product sales and bespoke developments, starting out as a COBOL developer on Tandem Computers back in the 80’s (yes there are a few of us still alive), apparently I could probably make a living still in certain government departments and high street banks based on my ancient technical skill-set, so I do know what it is like to be at the coalface and trying to deliver a project on-time and too-budget.

Modern development tool-sets and techniques mean that it is eminently possible to quickly and easily address the main reasons for project failure (see above), by adopting, proven approaches to iterative/incremental delivery (Agile or whichever other flavor you adopt) of functionality. As the organisation starts to see early delivery of their ideas, they can really get engaged with the process. Traditional Waterfall type approaches soon lost the audience as they required too much up-front investment and then a slow and painful delivery cycle that, eventually delivered something that was likely to be out-of-date, overly complex and had areas of functionality that were never used again. An Agile/Iterative approach delivers fast, adapts quickly as needs change, whilst still having all of the project rigor you need, when done correctly, to be sure you will achieve your business goals.

Sharp-cut bespoke or generic off-the-peg?

The issue for many is that an Agile/Iterative approach makes people nervous as no-one can say that ‘we will pay £xxxx for the system and it will definitely deliver yyyy functionality’ as that would totally missing the point and removing the benefits of the approach. I would argue that the benefit of this approach is that you can fix a cost of £xxxx for your project with an associated delivery timescale, the only difference is that your system will exactly meet your needs at the point of delivery/launch, it just won’t be what you thought you wanted at the start, will be of higher quality, be faster to deliver tangible business benefit and should offer you competitive advantage in your space (whether delivering slicker processes, or a more pleasurable and effective customer experience). I would venture that, a fixed price waterfall project is actually a false security blanket that places restrictions on both parties, removes the flexibility of a more trust-based relationship, fosters disengagement and results in the cost overruns and wastage that they are meant to avoid.

Nirvana – Integration of Pre-Built Components/Services – The Hybrid Approach?

Well almost, the more recent projects we have worked on have actually been a combination of ready-built components/services from cloud platforms/Open Source Projects etc., combined with a ‘glue’ of bespoke code to create a new and robust solution, leveraging the investment others have made in building core building blocks that add no real distinct business value in themselves, but which need to be there for most applications (such as Access Control, Password Management, CMS functionality etc.). This approach, when done with a level of due diligence on the source of these re-usable assets, can deliver faster, more robust (if selected carefully you are getting well tested and widely deployed code reducing time-to-market with code that should be bug free). Of course, re-usable code/components is nothing new (those of a certain vintage will remember Paragraphs etc. in COBOL), but newer technologies make this far easier with well-defined methods of integrating to make the most of reusable functionality.

If you are considering using technology to deliver significant business change, or to release your staff from mundane manual processes to focus on creating real value, perhaps, taking a step back from the perceived wisdom that buying a COTS package and squeezing it, or your processes to fit, might actually be the worst decision you could make ? You never know that highly risky bespoke software development project/hybrid might actually be fun too!

Interested in finding out more?

If you are considering the deployment of a new application (Web, Mobile, Back-Office) and are unsure which is the right approach for you, we’d be happy to help with an initial discussion to help you think through the options open to you, giving you our best advice based on (quite a lot of) experience. We even have a specialist teams focused on new tech such as block chain, deploying real world solutions that have a solid business case. No commitment to any more than a conversation to see whether we can help I promise.

[email protected]

/by Nick Poole

Writing beautiful code

Disclaimer: the author of this post is a biased, opinionated backend developer. There are a lot of articles/books about best practices, coding guidelines, which I’m sure the majority of us have read and followed. The following is not about that.

There’s always a battle between frontend (FE) and backend (BE) developers about the latter writing ugly code, because no one will be able to read it, much less understand it but them (and let’s be honest, sometimes, after a few months the ones who wrote the code will want to refactor it, but that’s life).

I cannot stress enough how strongly I disagree with this opinion. If you break down what FE/UI devs need from their BE counterparts, is actually a payload. Yes, it all boils down to an object (no matter the language) which they take, they restructure it according to the feature’s needs and then, voilà, they deliver it beautifully (if they’re lucky with the help of a good UX designer and CSS) on the screen.

However, I’ve seen ugly and equally beautiful code in the BE realm. But what is beautiful code?

Is it having the knowledge and the ability to use the latest coolest features of language “A”? Is it implementing the best design patterns fitting problem ‘X’? Is it (re)structuring the codebase in components/modules according to architecture ‘Z’? Is it adding comments? Is it writing (unit) tests for your functions (methods) in order for your peers (and your future self) to understand what the heck you’ve done? Is it writing readable code, often to the expense of not using cool programming tricks that may reduce lines in your code? Or is it about efficient code? And what about a legacy codebase? How can you write beautiful code, being technologically handicapped and unable to use the latest frameworks and new language features?

There isn’t only one answer. On the contrary, the answer is all of the above. And of course, it depends on one’s experience, comfort zone or even understanding their peers’ way of coding.

Although I believe efficiency is a very important aspect that drive us devs to write beautiful code, there is no way you implement one feature, writing what you think is beautiful code, if your peers cannot understand it. When someone first looks at your code, they want to see something self explanatory (from the method/class/package name), then delve into the backbone of the logic and understand it quickly, intuitively first and then in depth. It’s like reading a good book, page by page, in order, without turning them back and forth. The same with the code. Going from point A to point B to point Z, this has to have a meaning, a natural flow. If there are some unit tests, even better. Not only do they help strengthening your code in terms of bugs, but they also explain the logic behind the implementation of the feature and guiding you how to read the code, how to test it, how to debug it, etc.

Knowing the latest trends and cool features of the language helps, in terms of efficiency, clean code, but it’s not a panacea. Most of the times, the new way of doing things is the best way to go, but as with all new things, you have to really know how to use them and what purpose they really serve.

To recap, beautiful code is not about pretty code. It’s about understanding the purpose each and every bit your codebase serves. Finally, as with UX designers who care about user experience, I really believe that backend developers should care about developer experience, by being thoughtful to their peers and writing code that they themselves can understand and improve it or let others do that, when there’s a need.

/by Maria Michou

Ensuring your products get tested

A day in a UX designer’s life is rarely bereft of something to do.
Whether you are brainstorming approaches for new features, tweaking existing designs or simply going from task to task in the weekly sprint on the scrum-board, chances are you are not spending a lot of your time user testing.
And there are lots of reasons for that.

Designers are more than producers…

I’ve had a lot of roles where there was a lot of pushback to testing, because finding the time to test always fought with time to produce. This is where we need to assert the nature of the particular role we have and call into account the less visual and more scientifically based nature of the job.

This is where the scientist experiments, learns and evolves theories based on data and testing. We need to be allowed the same freedom and understanding in our roles, with all stakeholders knowing that this is not a nice-to-have, but an essential element to product development.

There will be certain clients you will face who will not have large budgets to spend on user testing. There will be clients, under pressure from stakeholders to develop promised features, who will prefer to see their money be spent on developing features as opposed to testing them. There will also be some clients who don’t see the benefit in the time/money spent in doing this.
It’s up to us to educate them.

At the end of the day, we know what the right thing to do is.
Our mission is to serve the users and so even if there is no emphasis on it from the powers that be (more likely, the powers that pay) then we need to take the responsibility to ensure that the products we bring to life are tested.
Pure and simple.

Why do we do this? A reminder…

  • Validate business assumptions
    This is your winning argument when selling the testing process to stakeholders. We need to ensure key business assumptions are validated before taking the leap and building something that doesn’t achieve the business objectives.
  • Gauge public opinion
    This is about not being precious about your design work, as well as your client’s concept – The users should be shaping the product. We need to have people use and feedback so that we learn all the stumbling blocks that we may not have realised were there, as well as whether it does what it’s meant to do in a straightforward and enjoyable way.
  • Decide on next steps
    User testing is critical to deciding the direction of the next round of funding, the next features to focus on or indeed, if the product continues at all. With user testing at all stages, early, middle and post, we ensure we are using resources wisely because we are always making the most informed choices at the time.

Fighting resistance

It is our jobs as UX-ers to ensure that the UX side of our titles is acted upon.
If the client doesn’t understand it, it is up to us to make the case for it and if there is no budget, do it on the cheap. Necessity is the mother of invention and imagination is our greatest asset. Take it as a challenge and don’t sit on your laurels. Get up and make it happen.
But first things first, be practical:

  • Ask the client why they are resistant to testing
    The first and most sensible thing you can do. Maybe your client has had a bad experience with testing in the past; maybe they are afraid of losing face with low fidelity designs being shown to the users; maybe they don’t have a budget for it. Find out their concerns, address them and sell the clear benefits of the process and all the ways it can be done, many of which are free.
  • Take the lead in organising testing sessions
    Getting buy in for face to face user testing sessions is a massive win. They can be as complicated or simple as you want them to be. The critical thing is that they’re well organised, not disruptive, particularly to your client or host.
    Send your user screeners pre testing, have your list of users and timeslots prepped, brief your client on what they are to expect on the day. Ensure privacy, internet connection, an assistant if necessary. Whether you’re on site in a clients office, or working remotely, have your day planned out to a tee, with contingency plans for everything.
  • Use one, or a few, analytics platforms
    From the moment you go live, you should be tracking your product’s usability and take up. Google Analytics is an essential but services like MixPanel and Full Story are also worth considering in to get even more insight. GA is free and provides incredible insights that allows you to easily find the areas you need to develop and consider while also allowing you to track user uptake and follow through. The analytics and metrics element of GA will also be more likely to appeal to the more data driven stakeholders than user sentiments and feedback.
  • Use free online resources
    There is a myriad of online tools and testing platforms that you can use to give you quick options without having to subscribe to big packages. For example, SurveyMonkey’s free plan, which allows you unlimited surveys, 10 questions per survey enables you to gather fast feedback from focus groups, without having to go overboard on costs.
  • Guerilla testing
    This form of testing involves going out into the public and approaching potential users to test your prototypes or answer surveys. This can be incentivised or not — Maybe paying for someone’s coffee in return for five minutes of their time, or simply an honest approach asking if they would be interesting in helping to develop an up and coming product.
    Done properly, with appropriate respect given the tester, both in terms of time and participation, this is a great quick-fire way of gaining immediate feedback.
    Use your colleagues
    Don’t have access to a user tester network? Use the people around you, ensuring they don’t have a direct connection to the project you’re working on. Even if they are not strictly the target users of the product, any testing is better than none – insight is insight at the end of the day and the feedback from someone completed disconnected from the project will be very valuable.

Prototype every feature

Aside from generally getting clients onboard for testing, you should really be prototyping as you go, it’s just a good idea. As you design, prototype each feature or user journey and test as soon as you can with whoever you can. This has benefits for multiple reasons:

  • Testing individual user journeys reduces the need for full scope testings
    User testing left until the end of development ultimately creates more work for us, as we need to test all features in either one sitting or condensed periods of time, which tend to tire the users and reduce the quality of their feedback, as they need to cover so much ground in one session.
  • Demoing to developers is easier and more effective
    In terms of working with developers, I always found it so much faster and more efficient to show my work on a prototype because as we went through, we would discuss, chat through potential issues together and ultimately speed up my iteration process with clearer insights as to how to improve. I thoroughly recommend this approach to any designer.
  • Any feedback is good feedback
    Whether you’re doing this using branded, high fidelity designs, or black and white wireframes, just do it. Don’t wait for them to achieve a certain level of perfection before you test, let them go. It is up to you to get the feature to the public in a way they can consume as they would expect to consume, note the reactions, hesitancies and general impressions and write these up to stakeholders and developers as validated evidence to make educated decisions on design.
  • Prototypes make amazing sales tools
    With existing prototypes, you have ready made assets for clients.
    Whether they use the actual prototype or a simple Quicktime screen recording of you using the prototype, having this asset makes presenting to stakeholders and potential investors so much easier and impactful. At the end of the day, the visual sells everything.

The UX process works, but you need to show them how…

Facts are facts and clients are more likely to respond to documented evidence proving your points as opposed to untested assumptions made by team members.

Testing, even simple testing using black and white wireframes, or paper prototypes, enables bias to be taken out of the equation, making it very easy to accept feedback and move on, in an informed manner.

This is where following up on testing sessions with comprehensive reports, laying out the main takeaways straight away, with clearly defined next steps going forward, is essential. This is where you get to show another side of your skillset, critically analysing the data and feedback and prioritising changes that will evolve the product in the right direction.

This is an empowering moment in the build-measure-learn loop as you are really taking point on steering the project at this stage and providing the real validation that’s needed to get to the end goal. It is one of the most critical elements of your role, so assert it, embrace it.

Enjoy the scientific side of UX and test every single scribble.

/by Róisín O'Toole

The Mountain Bites Back

It has taken me a little longer to write this blog than I planned, partly because there is a lot to reflect on and I was honestly knackered.

 

Firstly, the most important thing is to thank everyone who sponsored Xavier. We beat the £5k target so DRWF will get £10k towards their fight against diabetes. It’s still possible, if you wish, to donate here: https://www.justgiving.com/fundraising/xavier-shah

There is so much to say about this expedition that it’s a little difficult to put it into words, and any of you that know me, know that’s out of character!

Xavier and I chose to climb the Lemosho route up Kilimanjaro as it’s considered one of the most scenic treks even if it’s slightly more difficult. For the experience, this proved to be the right decision as we experienced a wide variety of landscapes during our 8-day trek.

 

We started in the rainforest, and as you can see, we weren’t the only creatures attempting to climb things! There were other larger creatures and lots of mosquitoes so it was a slight relief that within 2 days we had gone from lush green, humid rainforest teaming with black and white colobus monkeys into barren, scrub filled moors.

Kilimanjaro has amazing biodiversity with its five different climate zones and getting to see some of the weird and wonderful plants that only grow at certain altitudes was definitely one of the highlights.

By day 4 we had climbed to 4600m and thankfully neither of us were suffering from altitude sickness. I had spent 4 nights in a tent with my son and hadn’t needed to murder him. The down time playing scrabble whilst huddled in a sleeping bag to stave off the cold are moments that I will always treasure (especially as I made up words and tried to convince him they were real).

The following day was for both of us the highlight we climbed the great Barranco wall with an elevation of 257 meters which is more of a scramble than a trek.

Although we were not as heavily laden as some of the others in our group (with 20kg packs on their head, using no hands up a 40% slope!) our sense of achievement was palpable. By that evening we were in great spirits as we’d made such good progress, we were told we might reach the summit a day early.

It was at this point that the mountain bit back.

Overnight, the weather turned as big storms that normally don’t come till mid-November rolled in. The trek to Barafu base camp was long and difficult with gale force winds pelting us with hail and snow. There were times when we were struggling to move in the wind and the rocky ground was getting progressively icier. It was probably at this point that it first occurred to me that mountains can be dangerous. As we neared base camp the evidence of peoples struggles became clearer as there was equipment, baggage, food, tents, etc abandoned on route as people just tried to get through it.

The seasons on Kilimanjaro are pretty consistent and these late November storms are usually avoided by shutting down trekking for the season. These early storms were so unexpected that people were just not prepared, including us and even the experienced Sherpas. At base camp there was no shelter apart from the rangers hut where they were trying to prioritise getting those who were suffering the most dry and warm. This included Xavier, who’s so called waterproof gear just wasn’t. Hyperthermia was a real threat to many people and it was heart breaking to later learn that two of the Sherpas working with other parties died during the storms.

We were so lucky that our amazing crew of 10 Sherpas were one of only two crews that managed to get tents up stably in those conditions. Undoubtedly this is what kept us from hyperthermia and safe when all the other trekkers were forced to retreat down to safer parts of the mountain in the storm.

It was only the next morning that I could see how scarily precarious our tent was perched on the edge of the mountain and yet on the flip side of that, how close we were to reaching the summit. Experiencing the force of nature up close was incredibly sobering, equalising and humbling – it’s hard to put into words.

Despite the blue skies pictured, the raging storms soon returned and our route to the summit was closed, deemed too dangerous without snow and ice gear by Park Rangers. So, with just 4 hours left to go of our 8-day trek, we were stopped from reaching the top – denied by nature.

We retreated to the warmth and comfort of our hotel to share a beer with our crew who got us back safely. We returned to our family, tired and exhausted but grateful to be going home, thinking about those who wouldn’t be with their families.

Thank you to all of you who supported us and helped us raise an incredible amount of money for a very worthwhile charity. The money raised will enable DRWF to help change the lives of people with diabetes for the better.

Xavier and I are hanging up our hiking boots to dry out for a while before we plot our next adventure.

/by Bimal Shah