Gamification for business

­ “Employees’ engagement has evolved from money oriented approaches (pay-check, bonus, promotion) to a complex and diverse approach based on intrinsic motivational theory (mastery, autonomy, purpose)”

A current trend on supporting user engagement is gamification. Gamification is a concept of using game mechanics to non-game environments to create an engagement process to allow users to obtain higher perceived value of service use, such as social interaction or productivity of actions.

The game mechanics are closely related to game design addressing the human motivators of socializing, learning, mastery, competition, achievement and status. Gamification, deriving from game design, has the same underlying goal:

Generate positive experiences for the players/users engaged in an activity where interactive play is also referred to as “gameplay” focuses on the process of use, rather on the results of the process

The psychological aspects of gaming, i.e the user experience (UX) and the game mechanics are the tools for structuring and providing the gameplay, and comprise of rules, defined behaviour and user actions.

At present, the maximum impact of gamification has been on education and health environments. However, the gamification strategy is a concept emerging in business processes, and in particular in internal management of employees.

Gamification, following the structure of the gameplay (rules, defined behavior and user actions), can influence employees’ behaviour due to its use of motivational drivers of reinforcements and emotions:

  • Both positive and negative reinforcements encourage repetition of behaviours: behaviour leading to a satisfying outcome is likely to be repeated, while behaviour leading to an unsatisfying outcome is less likely to be sustained
  • Emotions effect users’ behaviour on whether they want to continue the activity or not. A mix of emotions is important for the user’s engagement. You need to have both positive emotions such as excitement, amusement, personal triumph etc. and negative emotions such as disappointment not achieving a reward to create a state of engagement

Successful gamification involves repetition of behaviours: by providing rewards and emotional responses for users following particular behaviours, then that can become an automatic user process or habit.

For example, I was recently asked by a client in the automotive industry to explain where and how these concepts could be applied in a scenario of motivating dealers to follow procedure.

In this context, the gamified business process can be utilised in influencing the desired behaviour – dealers to follow the same rules and procedures (business goal) and be rewarded for their effort to do so (repetitive behaviour).

The simplest game mechanics used here could be the ones relevant to competition and rewards which can take the shape of recognition status in a company’s dealer’s leader-board (emotional response on the high status among peers) and extend to dealers understand business processes as a result.

All organisations need to motivate and engage their employees – performance, teams’ collaboration and customer service are dependent on employee’s engagement.

In the example of automotive industry and the dealers’ network, the business depends on whether or not each dealer is mentally and emotionally focused on the company’s goal of following procedure, that goal is fundamental for the business success. Gamification can be an approach on achieving this. Taking lessons from the game domain, an effective gamified experience can motivate the users behaviour based on the desired business rules and goals, while increase users’ engagement participating in that experience.

Is it time for a game?

Leave a reply below or contact me by email.

Capturing tone of voice through role play

During a recent project redesigning an absence booking system, ethnographic research kept telling us one thing about the current system: its users didn’t always understand what was happening, or what was being asked of them through the journey.

While sitting observing the users navigate the current system, they made it clear that most of the copy in the journey did not help them to understand what they were doing, or explain what they should be doing. Terms such as ‘forecast balance’ and ‘absence compensation’ weren’t received well by the users, criticized for being ‘too technical’ and ‘unclear’. This left us wondering…

How could we make the journey more natural for the user?

In order to make any improvement to the system, we first had to understand the following:

  • What the system needs to know
  • How the user expects to be asked this information

The first part is not too difficult to determine. There are set questions the system needs to know in order to book an absence (the general what, when, where, why) along with some business-specific questions, such as including additional comments. For the most part, these were taken directly from the current system.

Things then started to get a little more interesting

We knew we had to create a system that could be used by everybody in the company, from top-level programmers to entry-level graduates, and become something that everybody could understand. We believed that finding a more natural tone of voice and a natural progression through the questions would allow us to create a journey the user would better understand.

In order to capture tone of voice, and the flow of the journey that the user expected, we set up a small experimental role-play exercise. Two participants were each given an envelope with a scenario in it. One participant would be acting as the ‘requester’ and the other be acting as the ‘grantor’.

CF workshop2The ‘requester’ was given the details of the absence they wished to book, including the type of leave, the date, the duration and the location.

The ‘grantor’ was given a list of details they had to find out, including the type of leave, the date and the duration. They were also provided with some information about the user, including their remaining holiday balance.

CF Workshop1How the two participants asked the questions, which questions they asked, and in what order, was entirely up to them. They were provided with the scenarios and a selection of post-it notes, pens, paper and calendar templates, and allowed to use as much or as little of it as they saw fit.

We ran five scenarios in total, each targeting a slightly different aspect of the current system, allowing us to hear how the participants would interact when booking an absence. Two of the scenarios included errors which allowed us to see how the participants would communicate to each other when something wasn’t possible to do (i.e. having no allowance left to take).

The results highlighted a number of observations

  1. Deciding who went first in the scenario varied. Two groups started with the ‘requester’ asking to take an absence, and three groups started with the ‘grantor’ asking the ‘requester’ if they would like to take an absence. While not directly important to the journey (the ‘requester’ will always go first as they will have to launch the app/webpage) it was interesting to see how they decided this. In most cases the participants stated they didn’t think about who went first, and just started the exercise
  2. The order in which the questions were asked varied from group to group, but remained relatively similar. Most groups followed the flow of asking the date, the duration, the absence type then asking if there was reason for taking the absence. One group however checked what type of leave the ‘requester’ wanted to take first. There was nothing unexpected from the order that the participants picked
  3. The language used by the participants was far more natural than that of the current system. In one instance the ‘grantor’ started the exercise with “Hello Nick! What date would you like to take off?” This showed a far more personal approach compared to the current system. Other phrases used that were more natural included “What type of leave would you like to book?” as opposed to ‘Select absence type’, “What date would you like to take off?” as opposed to ‘Start date’ and ‘End date’ and “What dates do you want to remove” as opposed to ‘Cancel’.
    While in some instances these phrases may be too long to use on a form (think mobile), the more personal tone of voice used in each instance, helped the ‘requester’ understand what they were doing more clearly
  4. How the participants chose to communicate to each other varied between groups, with one group opting to use the printed calendars to pass the dates to each other rather than speaking verbally. This allowed them to visualise what each other was trying to accomplish. Another group followed the same principle, but using post-it notes instead. This ensured that they both knew exactly what was being asked/told. Other groups stuck to the traditional verbal communication, taking private notes to remember what the other participant had said. The visual methods were interesting, with all users stating that having a way to see what they were doing would be beneficial

Overall, while this exercise didn’t provide us with any ground-breaking or divergent ideas, it did allow us to hear first-hand how the users would interact in person, and gave us direction for creating the journey and making it more natural for the user. It allowed us, through a relatively simple task, to understand to a far greater depth what language was most appropriate for the system to use. Having this information is incredibly beneficial to the project, and allows us to create an experience that will be more user friendly.

For further studies, it would be of benefit to get a broader set of users to participate in the workshop, as the pool of users who participated were of similar persona. While there were a lot of similarities in response, the tone of voice did vary slightly; therefore a more varied group of participants may help us make the language more accessible for a greater amount of people.

What is your experience of using role play in system design? Leave a comment below or contact me by email.

Why do we design “mobile first”?

What does mobile first mean?

Mobile first design refers to the philosophy that the solution should be designed for smaller screen sizes before creating design solutions for larger screen sizes. This is based on the underlying idea that is it much easier to scale a design up than it is to try and squeeze elements into a smaller area.

This concept came from the development and design approach of responsive web design. This uses “break points” at specified widths in the document to display a different design or layout in response to the width of the browser in which the document is being viewed. This allows for the same codebase to display different layouts in response to the width of the document.

Why mobile first design?

When the responsive design approach first began, many designers were so used to creating designs to be used on desktop or laptop devices that they instinctively started with that type of layout when creating a new design.

This caused a lot of issues and complications, as the information being displayed in a large screen format didn’t display well when being forced into a much smaller screen space. Important information was lost, hidden down a long scrolling screen, or removed altogether as designers decided that users only needed limited information on smaller screens or mobile devices.

The approach of designing for the mobile first, or from the smallest screen size up, means that the designer has to think consciously about the importance of content in the information architecture. As the screen size increases the areas of content can expand and be realigned into layouts that make more use of the screen’s real estate.

Focusing on the information architecture from the beginning means that the most important and noteworthy information is presented where it is easily discoverable. Information of less importance is displayed in areas of slightly less importance, and so on.

This approach lets the presentation of the content in relation to its importance guide the layout of the system.

But the system doesn’t need to work on mobile?

“Mobile first” is simply a name. It was coined when the philosophy was first developed to clearly articulate the need to design websites for mobile devices such as phones and tablets before designing layouts for larger screened devices such as laptops and desktop. Even in such a short period of time the name has become antiquated, but is still in use, even when “smallest screen first” makes more sense.

Even though a system is not to be built to work on mobile devices, the philosophy of designing for the smallest screen that it could be displayed on first, before scaling up to larger screen layouts remains. Thinking about the information architecture in detail before beginning any design will always provide better results.

What are your thoughts on website design? Leave a reply below or contact me by email.

UN-tangling accessibility

On the occasion of 70th Anniversary of the United Nations, there has been an initiative to raise awareness about the importance of web accessibility. As a measure of immediate change, the organisation has started to improve all the UN websites.

Logo: accessibility guidelines for UN websites

UN Secretary-General Ban Ki Moon’s thought-provoking article stresses the importance of eliminating digital barriers. This also includes a brief but highly effective video highlighting the importance of accessibility and this notable line:

Accessible websites benefit all visitors, not just those with disabilities. On an accessible website, the user is put at the centre of the experience.

This is a lesser known fact about accessibility. Apart from the obvious advantages of creating an inclusive environment and increased market reach, accessibility enhances the overall user experience by improved clarity and structure. One of the hidden benefits is improved search engine rating (in fact Google essentially is like a blind person looking for information). But above all, it is all about acknowledging the diversity in the end user community, accepting the fact that we are all differently-abled due to many factors.

I’m passionate about User Experience (UX) – improving the digital experience for the user, particularly for the disabled users. So to learn about the scale at which this is being taken up by UN is very energizing. It is high time that this topic garners the attention it deserves. It is legally, ethically and commercially important make technology a level ground for those with disabilities. A live example of its benefits is the legendary scientist Stephen Hawking who uses various assistive technologies to express himself. What a loss it would be for the world to not provide that opportunity to participate!

Today’s IT service providers have to sit up and think what they are losing by not getting their act together in terms of accessibility. In fact, it can be considered a discrimination for a service provider to host an inaccessible website and hence be subjected to legal action. However, rather than fearing accessibility for such reasons, there is a strong case for businesses to consider improving web accessibility because of the positives it brings with it. There have been glorious examples of businesses reaping benefits by making their websites accessible. There have also been some infamous stories about those who have paid a price for disregarding this aspect.

To be fair, there have been some examples where organisations have put accessibility on the top of their list, particularly where a new system is being built. For example, during the development of GOV.UK portal (Government Digital Service), I am told that the delivery would not get progressed to the live environment unless there was a complete approval on the accessibility aspect of it. However such examples are far and few between. Sadly, most seem to have chosen to push it down their ‘to do’ list. In some cases it is seen as too significant an area of impact on development processes and hence not to be taken too lightly. i.e., hold a lot of discussions rather than take any action. Why do they do that I wonder?

Existing websites, old technologies, ongoing business, impact on BAU?

Accessibility is not easy to understand. You need to involve people with disabilities to fully realise the problems. How easy is it to engage people from that community in the software development process?

ROI: is there really an audience or are we just going through a lot of hassle for a small minority?

We need specialist companies to do justice to this topic; can we afford to get them on board?

Well, let us face it, all these factors are actually very real. I very much empathise with the businesses in the challenges involved around accessibility. It is a long way to achieve the utopian idea of fully accessible websites across board. But to me, the first step is not the implementation – it is to develop the will to support accessibility, to include it in the thought process, to talk about it in meetings, to encourage innovation around it, to consider investing in it. In my opinion, there usually is not enough research done before concluding that it is not for now, it is a topic to be taken up some day in the future.

This actually calls for a change of perception and practices, a real determination to make disabled users feel more welcome. There are some immediate measures a business could take up to reflect an inclusive line of thought. For example, carrying out an audit on the existing websites to understand the current issues is a good starting point. Implementing easy fixes sometimes does not call for a huge investment. Publishing an accessibility statement on the website is another recommendable measure, to acknowledge that there are known issues and to offer the users a way to report the issues they are facing. There could be other innovative, technical solutions to accessibility issues. There is a lot businesses could do, if there is a will of course.

We might want to take a cue from the construction industry. In today’s age, there perhaps would be no new building without a lift or a ramp. Even in existing buildings, there have been excellent examples of creating an accessible route with minimal impact to the structure. It is perhaps very natural for architects and engineers to factor it in by default. It is perhaps a matter of time before accessibility in IT attains a level of importance it gets in building constructions. But we IT professionals can make it happen sooner – for the sake of 15% of world’s population, for the sake of equality and human rights, or perhaps for the sake of our own old age!

And how do we do that? By learning more about it, by raising awareness, by talking to our customers about it, by trying our best to include it in our proposals / web designs / user interfacing programs / testing activities. It is our choice to be just an audience to this initiative started by the UN or to be an active part of it.

Please spread the word!

What are your thoughts on web accessibility? Leave a message below or contact me by email.

Demystifying UX: it’s just like riding a bike

What is UX design?

Ever since the term “UX” (User Experience) design started being used a number of years ago there has been a bit of confusion, especially with clients, as to what UX design actually means. We can explain the methods and processes that we use, but it has always been a bit of a vague description.

The main confusion tends to be that people think that UX design is just a fancy name for (UI) User Interface design. It’s very easy to see how this could seem the case. A lot of the deliverables that a UX designer produces can be very similar to that of a UI designer, but there is also a lot more work going on behind the scenes that is done to produce results that are not as easy to see.

How can we clear this up?

There is always a difficulty in creating a mental model of a digital product. Even with digital products that we use every day, such as email. We tend to default to the visual cues of the product, the email or the inbox, when describing its processes, even though there is a huge amount going on in the background.

One of the reasons for this is that digital products are intangible. We can’t easily lift open the lid and see how all the gears fit together, so this makes it difficult to describe how they work and what they do.

It is a lot easier to explain what a physical product does, because it’s a lot easier to show how it does it. It’s more straight forward to open the back of a clock and see how the bits fit together than to show someone code and explain how it fits together.

A better way to describe what UX design is, would then be to relate it to a physical object that everyone can relate to, and explain how the design of the product is changed to create an experience for the user.

The product

Let’s take a bicycle. It’s a simple product that has been produced for many years and that everyone can relate to. When someone mentions the word “bicycle” or “bike” there is instant recognition as the shape of the product forms in the mind. No more information is provided at this stage, but with what limited information is available, a model is constructed.

The products components

As with any product there are different components that come together on a bike to create the whole. Some of these components the user interacts with directly, while others are there to allow the bike to perform its function. The user interacts with the handlebars, which  turn the front wheel, which steers the bike. While the user does not interact directly with the wheel, the effect they supply at the handlebars directly influences the wheel, which causes a change of direction.

Using this analogy, the cyclist’s interfaces with a bike are all the areas with which they actually interact to perform the task of cycling. These include the handlebars, the seat, the brake levers and the pedals. The other areas of the bike are what could be described as the “back-end system”. These are the components that control how the bike actually works, and the tasks that it performs. Examples of these are the wheels and bearings, the forks, the gears and the chain or the brake cables and pads.

On a bike it’s very easy to see how all these elements connect together to form a whole product, and how a user can interact with the product to create their end user experience – cycling.

How can the experience of “cycling” be designed?

It’s easy to understand what cycling is, but quite an abstract concept to explain. There are lots of elements incorporated into the experience of cycling that go beyond just the experience of interacting with the bike as a product.

The experience includes the feeling of speed, the wind rushing past, the feeling of leaning into the turn going around a corner, the muscle soreness from pedalling and the feeling of cruising along a smooth piece of road. This experience is the culmination of a number of factors including the product, the cyclist and external factors such as the gradient, the type of surface and the speed at which they are cycling.

This means that it doesn’t make sense to say that we are designing “the experience” as much as we’re designing with the experience in mind. We want the experience to be positive, but we can’t force it to be.

Designing without UX

A product like a bike can be designed without using UX design. It would involve being provided with a brief from the client and creating it with the information available.

A designer could have seen a bike before, or cycled a bike before, or even designed a bike before, so they would have in idea of what a bike should look like, and how it should work. They would pull on that experience and create a prototype that fulfils the requirements set down and with which the client is happy. It has handlebars, pedals, a seat, wheels, gears, chains and brakes: everything that the user needs for the bike to work and for them to be able to cycle on it. The client makes a few changes to the design, and the prototype is created into a product.

This method of design can create a usable product, and can create the experience of “cycling” for the user, but we don’t know if the experience is a good one. There are a number of factors that were not considered and, as such, might mean the user having an unpleasant cycling experience.

Designing with UX

Some of what is mentioned above also applies to designing with UX. Once provided with a brief from the client, the designer may have a rough idea of what a bike could look like based on their previous experience. This would not, however, be the design that the client sees. There are other steps that will influence the design before then.

The first step is to ask the client why they want to produce a bike? Who are they making it for? Who is the target audience? What are the goals for the business when producing a bike? All companies need to sell their products to make profit so that they can continue to operate, although some have very different reasons for doing so.

For this example, let’s say that the target market is 16 to 24-year old males, and the company wants to make a profit by selling enough of their bikes, but they also want the target market to associate their brand with well-designed, solid products that perform at a high level. This information can be used to create “personas”, which gives the designer a reference point for all the design decisions that they make throughout the project. It is to ensure that they are designing for the user, not for the client or themselves.

Now that we know who target market, and the business goals for the product, we can start to research what the target market want from the product, and how competitors that already have the desired brand image have achieved that goal.

User research with the target market will discover that a large number of 16 – 24-year old males are interested in mountain biking. This includes cross country, trail and downhill mountain biking that can be done all over the country, and also at specific specialised areas in forests and national parks.

The competitor analysis of other companies in the area shows that those who produce quality, high-performing products use strong, solid and light materials, and have put their products through rigorous tests to prove that they perform at the highest levels. Research into these products give the designer an idea of what designs have proved to work successfully, and can influence the product that they are creating.

Using this information, the designer can begin to create a prototype that is tailored to the target market and the task identified, is using the appropriate materials, and is using known effective design solutions. The designer will also pull on their own experiences from previous products that they have worked on and incorporate them where appropriate.

This prototype is then tested with users in the target user group and in the environment where it is most likely to be used. It is unlikely that the first design created will be the most optimal, so the feedback provided from this testing is fed back into the design followed by further cycles of testing and design iteration until the design is the best that it can possibly be. Only then will the design be put into production and the final product created for sale.

However, this isn’t the end of the product life cycle. The designer should take feedback from those who have bought and used the product extensively to see how it can be improved, and release regular updates to the product, creating versions 2, 3 and beyond, getting closer and closer to providing the best cycling experience for the cyclist.

Just like riding a bike

It’s clear that the bike produced using the non UX method will create a bicycle – it will have handlebars, a seat, wheels and all the other components that make up a bike, but if it was used in the same scenario as the one that was produced using the UX design method, then the experience for cyclist will be very different.

So, UX is just like riding a bike, but the experience can vary quite a lot depending on the bike.

What do you think? Leave a reply below or contact me by email with your thoughts.

The UX “snowball effect”

How transforming the user experience can deliver rapid, ever-increasing business benefits

A key strength of applying a user centric Agile approach to digital transformation is that it can deliver incremental improvements to the customer and employee experience without having to reconfigure an organisation’s entire operating model “all at once”.  Furthermore this approach can enable further benefits to be potentially realised across the whole business.

These improvements alone may not always generate great bottom line benefits for different organisational stakeholders, but cumulatively they can have a massive (“snowballing”) sustainable impact.  Also this approach may be the only way smaller organisations can realise the benefits of digital ways of working and technology at an acceptable level of risk.

Here’s an example of how this UX snowball effect could potentially deliver the tangible business benefits of digital transformation in less than one year for a medium sized high street and on-line retailer (note all change activities described in this scenario are tactical, not strategic):

  1. An on-line channel requires users to complete a free text form; the process is cumbersome for customers leading to a significant number of complaints and drop-out to off-line sales channels. Based on customer and service centre feedback, the onsite UX team designed and implemented a new on-line form that uses drop down menus. This made the process of completing the form for all users easier and more responsive – and resulted in more on-line purchases and a reduction in complaints
    Cumulative indicative benefits:  improved customer satisfaction score 
  2. Because the UX team used Agile to deliver this user experience enhancement quickly in collaboration with the customer service centre management team, these stakeholders were able to rationalise back office capabilities in parallel that generated cost efficiencies
    Cumulative indicative benefits: improved customer satisfaction score + reduced costs to serve 
  3. The significantly reduced admin burden meant sales staff could focus on higher value engagement activities such as engaging new customers
    Cumulative indicative benefits: improved customer satisfaction score + reduced costs to serve + increased new customer acquisition 
  4. The user-friendly on-line form also enabled cleaner, more accurate data to be collected about customers’ browsing and purchasing behaviour; using money saved from back office efficiencies, managers invested in analytics/reporting tools to create a better understanding of customer needs based on this deeper information. This insight meant the company could pro-actively respond to the changing demands of individual customers
    Cumulative indicative benefits:  improved customer satisfaction score + reduced costs to serve + increased new customer acquisition + data driven personalisation 
  5. Using insights gathered from the data analysis, marketing were able to use this evidence to build a business case for new innovative services that addressed genuine gaps in the market
    Total UX “snowball benefits” realised in one year: improved customer satisfaction score + reduced costs to serve + increased new customer acquisition + data driven personalisation + lower risk diversification

…And all resulting from innovating the user experience for completing an on-line form!

If you would like more information about the issues discussed in this post, or how digital transformation can benefit your business, please leave a reply below, or contact the Sopra Steria digital practice

UX Designers HQ: UX Hackathon

Have you ever woken up in the morning and wondered “Did that actually happen or was I dreaming?” That was my exact thought as I groggily arose from my warm bed recently, unsure of whether or not I had attended a game-changing event in the world of UX. It wasn’t until I scrolled through the abundance of notifications on my iPhone with the tag #CFUXHACKATHON attached that I realised not only had the event actually happened, right here in central London, but also that I was not alone in my feeling of fulfilment.

Many members of the digital community have often walked away from an event that has a UX focus to it, still with so many questions left unanswered. UX is such a complex discipline, it is hard to keep up or even retain the information being spoken on stage by the UX thought leader of the moment. The digital community in the UK has long awaited an event where they can leave and go to bed knowing more, understanding more and being more than they were when they woke up that morning. As the hope was slowly beginning to drift away, along came the meetup group UX Designers HQ: London. The organisers (Career Foundry) promised an intense, knowledge filled six hours of UX-iness, in the form of a UX Hackathon, which is believed to be the first held in London of its kind and scale. Was this the event that the community had been looking for? We all waited in anticipation for the date of the six hour UX Hackathon to be announced; Wednesday 25th February 2015 at 6pm.

6pm mid week? Haven’t we all go work in the morning?

Despite the fact that it was on a work night 100+ members from the digital community arrived, representing some of the biggest technology companies globally and of all abilities, knowledge and experience in UX.

The Career Foundry team had asked me and six other UX professionals to mentor the twelve teams during the hackathon based on our experience practicing UX in specialist areas related to the briefs that the teams would be working from. The seven of us also formed the expert judging panel, where we provided critique and scored the final presentations from our UX Hackers.

Mentors/Judges:

  • Jay Tulloch – UX Designer at Sopra Steria
  • Yael Levey – Senior UX Designer at the BBC
  • Sandra Sears – UX Designer for TalkTalk
  • Andy Iosifescu – Freelance Interaction Designer
  • Neil Sampson – Professional UX Designer
  • Paola Miani – Senior User Experience Consultant at IG
  • James Walters – UX Lead at Open Inclusion

The night flowed extremely smoothly with the teams getting acquainted and well and truly stuck into the tasks at hand.

The Hackathon consisted of five stages:

  1. User research and prep
  2. User testing 1: User Interviews
  3. Divide, coordinate & conquer: value proposition, user flows and information architecture
  4. User testing 2: paper prototyping
  5. Iteration & pitch

As a mentor, it was my job to add value to teams and help direct them through their design brief, providing them with the in-depth UX knowledge and methodology required for them to really understand the needs and goals of their ideal target users. I soon found myself being called to different tables to provide my insight and expertise. This was great! It meant that the information that I was sharing not only made sense but was indeed valued. By the end of the night, all of the twelve teams had confidently presented their final designs to us judges and there was uproar of applause from the audience for everyone involved.

The feedback from the attendees both directly and on-line has been incredible: thanking Sopra Steria for sharing our expert knowledge and experience in the UX field with them, which they found invaluable during the tasks. Participants and Mentors alike displayed a keen interest in the great work that we are all doing in digital transformation at Sopra Steria. The organisers have been praised in huge amounts for the event, and they are planning a full three day UX Hackathon in nine months time for over 300 participants! This is another event which could provide Sopra Steria with the opportunity to further increase our influence as thought leaders, as we continue to make our own transition from the New European Leader to the New Global Leader in Digital Transformation.

Read on, for a timetable of events

STAGE ONE: USER RESEARCH

Competitor Analysis

Teams researched three competitors who shared the same goals as the teams business concept. It was important for the teams to understand their competitors in order to begin to form a picture of their target users. I asked the teams to think about:

  • Who are their competitors communicating to?
  • How are their competitors communicating?
  • Why are their competitors communicating in this way?
  • What is their competitors message?
  • Is there a story behind their business?
  • Do their competitors values match theirs?
User Personas

After identifying three of their closest competitors, the teams were asked to create a single persona which described their ideal target user of their product or service. It was important for the teams not to be distracted by the look, age and name of their persona. They needed to look deeper into who the person actually was and think to about:

  • What are their interests?
  • Who do they socialise with?
  • Where do they socialise?
  • What are the motivations for using their product/service?
  • Goals, what does their persona want to be or do?
  • Is this why they are using the product/service?
Card Sorting

Card sorting was a fun exercise that really brought the team together. They rolled up their sleeves and got stuck into this task and were asked to maintain focus on their vision for the product. Once they grouped their ideas into categories they carefully prioritised features, ideas and pages that were must haves for the MVP of their product/service.

STAGE TWO: USER INTERVIEWS

The teams went out into the big wide world (the table next door) to find representatives of their target audience, and ask them questions based on the teams assumptions of how their users would interact with the product or service. The task was very insightful and the teams soon realised that the answers that they received were not those that were first expected.

STAGE THREE: BRANDING, USER FLOWS AND IA

A huge task which required the teams to be very organised. Based on the data obtained from the user interview stage the teams went about creating the optimum user journey through their proposed product. From this, they could then begin to develop the information architecture and place in the features and ideas that they had prioritised for the MVP. When constructing the IA, I discussed with the teams the importance of how information is delivered to the user through content (labelling, hierarchy, tagging, grouping), which allowed them to question some of their own decisions and assumptions, and provided a starting point for the next round of user testing.

STAGE FOUR: USER TESTING w/PAPER PROTOTYPES

Another fun task, however, one of the most valuable. The teams tested the paper prototypes of their proposed user journeys and interactions with users from other teams. None of the teams got the design right first time, and that was ok because they gained invaluable insight into how their users actually will use their products and what their expectations really are.

STAGE FIVE: ITERATION AND PITCH

They now had the opportunity to refine their design before the final presentation, it was critical to the success of their product that they utilised the helpful feedback obtained from the user testing stage. The data received from the testing would help them to direct their iterations towards the needs of their ideal target users.

Once they were satisfied that their final design was a perfect fit for the needs of their user the teams began to organise how they would pitch their vision to the audience and more importantly the judges.

All twelve teams pitched extremely well and delivered the goals from the brief. Some of the pitches were long, some were short, some were fun…and some were not so much. At the end of the night, there was not a single person without a smile, and there was a brief moment where everyone could see the satisfaction in the faces of their team mates. The whole room congratulated one another and it was clear to see that the night was one we’d all never forget.

FEEDBACK

Apologies in advance for the “cringe factor” of the following images. Although I feel strongly that this feedback is important for us to know and it does not only reflect the work that I did on the night, it is also reflective of the awesomeness of us as a UX and Innovation team at Sopra Steria and the work that we have all done over the last two years building our Digital Practice from the ground up to get us into spaces such as this one.