Hourglass: Transparent Timekeeping

How a simple conversation with a client about time-keeping led to some late nights, reflection on project tracking & a simple progressive web app…

Good morning/afternoon/evening (delete as appropriate)!

My name is Bryce Wilson; Lead UI developer for the UK Design Team based in Edinburgh. I currently work across multiple projects and platforms and it can be hard to track what I work on and for whom. For the client, it can be frustrating when they can’t get a fixed timeline on my availability.

Around the same time I was coming to the end of ‘yet-another-notepad’ scribble of loose time keeping, I had a chat with one of the project managers for a fantastic client I work with.

He was concerned that he wasn’t able to have a visible overview of all the contractors and consultants in his team. This is primarily down to the flexibility the project offers to the team; early starts, late finishes, working from home on occasions etc.

This screamed out an opportunity to fill a few needs with one deed:

  • Upskill myself on a few new technologies I’ve been itching to try
  • Get rid of my legion of notepads with illegible cave drawings and scribbles
  • Supply a very cool and awesome client with a solution that will enable them to continue providing us with a flexible working environment
  • Demonstrate to the wider community a landslide of user-centered design approaches being developed daily within the UK Design Team (headed up by Luke Jeavons) such as:
    • User Journeys – A visual representation of a path a user may take to reach their goal when using a particular product or service.
    • Usability Testing – To validate the effectiveness of the design and the way the user interacts with the system. This can highlight potential inconsistencies and issues with the product or service.
    • Wireframes – A visual guide that represents the page structure, as well as its hierarchy and key elements.
    • Interactive Prototypes – To show how interactive elements will work. Enables the product or service to be visualised, tested and validated before further development.
    • + much more

After speaking with some fellow upstanding colleagues, I took it upon myself to define an MVP backlog of simple requirements:

  • Allow access to a ‘clock-in’ system via any device and bypass any requirements for an installation
  • Login with work email
  • Allow manual entries of working hours
  • Allow a clock in/out feature
  • Keep it simple, avoid that (points in horror at existing time reporting tools in the market)

Given this was a pet project I didn’t want to overreach and take focus away from day-to-day within the Compass project and the Design Team so I gathered my weapons of choice and began.

Frameworks & Services

In order to maximize the time and effort spent getting this from farm to fork:

  • Contentful – an AMAZING headless CMS that has insane API control and access. I have utilized this to store and retrieve data in a fully secure environment
  • Vue.js – The MacDaddy of JS frameworks. I work with Angular, React, Node, etc and Vue.js slays them all dead. End of.
  • Element.io – A clean and simple Vue.js orientated components library for all the basic needs
  • Azure – The Sopra Steria single sign-on application front
  • Heroku – Free and simple app hosting with CD/CI Pipelines
  • Custom Node.js API Service – I have developed a customised API service to enable continuity of other applications I have created (regardless of framework) to knit together user and information

It started with a few hours in the evenings while my expectant wife lay on the couch binge watching Forensic Files (If I suddenly disappear, you know who to point the finger at!) I melted into my coding chair and got to work.

A few nights in and it begins to take shape; implementing simple features such as project and team control which is operated in the Contentful Dashboard. This allows me to add additional projects as they come up.

The first release of the app to my inner circle highlighted some interesting results:

  • Observation: One user found it difficult to navigate their way back to the current week & also found it time consuming to try to get to December for example, to input time
  • Suggestion:
    • Implement a ‘jump-to’ week selector where it displays the week information; allowing the user to easily jump forward or backwards in time
    • Always have ‘current week’ at the top of list to highlight the current week
  • Observation: Initial version did not allow for non-project codes such as holidays, training or meetings to be logged
  • Suggestion:
    • Allow time to be logged to ‘non-project’ codes through the same interface
    • Allow team leaders to see these days on the team leader view. This allows the project leader to see upcoming days where we might not be utilized. It’s no fun for the client sifting emails and syncing calendars to see why ‘Dave’ hasn’t shown up today!

Reaping the Hard Miles

A few seasons into Forensic Files (my wife at this point now knows how to dispose of a body in 50 different ways, just saying) and we start to have something testable!

As the app is cloud based I fired out a link to a few trusted amigo’s and it seemed we were pretty close to the mark!

With the intended users now having something tangible in their hands, the next goal was to give the client the keys to the kingdom – an external (or internal) team leader view.

A non Sopra Steria user can be set up within the system to retrieve all entries which are assigned to their project, including holidays, sickness etc.

Given that a lot of our teams are also internal, a Sopra Steria employee can also have a team control panel if they are assigned a team leader role.

The Verdict

After picking a handful of users to test the app, we took a period of 1 week to collect initial feedback and log any issues.

Each user was asked to carry out specific tasks and report back, for example:

  • Successful and unsuccessful clock-in/clock-out experiences
  • Test on different devices and networks (firewall etc)
  • Log upcoming holidays

The feedback from actual ‘live’ usage resulted as:

  • Request ability to add ‘half-day’ non-project events
  • Improve performance for older Android phones (now complete)
  • Return to same week that a logging was added to (now complete)

The client is very happy with the outcome so far and has adopted this very early MVP into the projects daily routine!

There is still A LOT to add to Hourglass but given its been about 40 hours of development from a single developer and some fantastic sound advice and guidance from the UK Design Team – I reckon it’s not half bad!

If you would like to ask any questions, please get in touch :


Everything is connected. Don’t innovate in isolation

…These are the words Alberta Soranzo left the audience with as she drew the final keynote speech of this year’s UX Scotland conference to a close.

Alberta, who was recently appointed Director of End-to-End Service Design at Lloyds Banking Group, strives to make a real impact on the financial outcomes of people by taking a look at both the big picture as well as focusing on the very small things, which she believes ‘matter a lot’.

Alberta stressed the importance of nurturing diverse talent and stated that it is vital to foster a culture of continuous learning within a design team. This is something that resonated with me as a culture we are striving to cultivate here at Sopra Steria — through hiring a diverse range of people from a whole range of different backgrounds and with differing areas of expertise. However, most importantly, each of these individuals share a desire to learn and continually improve. This allows the design team to avoid the previously mentioned isolated innovation which Alberta warned about and work as a team to grow and develop.

Those who attended UX Scotland may well have met the various members of the Sopra Steria team who were there – either during the various workshops and seminars on offer or at our stand in the foyer. Some may even have entered our interactive competition which invited people to ‘step into out customers shoes’. Through sponsoring the stand we were afforded the chance to speak to a whole host of interesting people during our time at the conference, including a couple of people who have since interviewed for and accepted roles within the Service Design team at Sopra Steria.

Over the course of the three day conference we got the chance to experience a number of great talks by a range of different speakers. We were given the opportunity to hear from leading industry experts such as Jared Spool and Dana Chisnell. We were also able to take part in the various workshops on offer which allowed us to develop our existing skills as well as learning new ones.

With many of the talks and workshops occurring at the same time, there were understandably frustrating moments where we were unable to attend all the talks that we would have liked to. Thankfully, with so many members of the team present at the conference, we were able to minimise the effects of timetable clashes by spreading ourselves across the events which occurred at the same time. By taking notes during each session, team members were able to report back and share their knowledge with the team who were unable to attend.

Our Service Design team listening to Jared Spool’s keynote speech
Our Service Design team listening to Jared Spool’s keynote speech


This notion of shared knowledge strikes right to the core of what Alberta Soranzo was talking about during her Keynote speech. By avoiding innovating in isolation, and looking at development at a wider level, it allows the team to grow and develop their skills at a greater rate.

By allowing everyone to benefit from the knowledge gained at events like this, we help cultivate the culture of continuous learning and as the old adage goes, allow the team to become more than the sum of its parts.

What do you think? Do leave a reply below or contact me by email.

New Year, New UI Toolkit

Everyone knows January is the ultimate time to undertake new challenges to better yourself, so why not apply the same get-up-and-go to the projects and challenges you face in your career path?

The Problem

One of the biggest issues facing UI (User Interface) development in the public/private sector today is that once you drill down past the surface it lacks consistency and understanding. It is easy to see why this is the case given that, in an environment such as a client side project, the UI development task is often assigned to someone with ‘a bit of experience’ with HTML or CSS. In this scenario, the developer would do what they normally do and get the results they normally get.

That is in no shape or form a criticism to said developer, they have merely been tasked with something outside their field through ignorance of better fundamentals.

To highlight the lack of consistency and understanding, I will summarize the widely absorbed and in-practice approach to general front-end development adopted in the majority of client side projects:

The project is developed not as two separate entities but as whole unit, the front-end becomes part of the machine that develops roots that only grow deeper as development continues. To add to this, it is usually always developed in such a way that it contains no best practices or full understanding of the tech stack and the alternative options available.

When a project is allowed to continue like this it becomes unmanageable and unmaintainable so when it comes to pass that issues with the UI and development have been ‘discovered’ it’s too late to do anything of any substance that will turn it around and instead you are left with your only available option – bring in a ‘UI developer’ to sit and painstakingly churn through code which is not native to them and fix bugs until the end of history comes about.

This HAS to change. This NEEDS to change.

The very definition of UI Design and Development has changed drastically over the past few years. No longer is it acceptable to bring in a ‘UI Guy’ in the final stages of the project to ‘Make it pop‘ or ‘Make it usable‘. To attain the results the project so desperately needs in the end-game, foundations need to be laid right from the get-go of the project.

That means letting the UI Developer use their knowledge and expertise to guide the experience set out by UX Designers, letting them use their own tools for the job and, above all, recognising that the front-end needs to be its own entity and not just an afterthought.

The Solution

You guessed it… the UI Toolkit! Well, that AND the whole part about recognising the issue and addressing it.

Over the past few months, our collective thoughts, ideas and woes in the UX Department have been brought to life in the shape of the UI Toolkit. What is this UI Toolkit and why is it so special, I hear you ask? Well, I’ll tell you…

What if I told you that in the weeks prior to any back-end technical work beginning on a new project, you could have a fully-working, production-ready application in your hands, for which you could gain critical feedback months ahead of schedule? That you could code to such a high standard automatically that when it comes to integrating with the actual back-end and databases, it does so at the flick of a switch? That it will take days, not weeks or months, to convey the UX designs from wireframe to production-ready screens?

I could be here all day asking you these kind of questions but I am here to give the answers to these and questions you wouldn’t even think needed asking.

Our UI Toolkit comprises separate modules designed to work flawlessly together. Quick, effective and progressive in nature – it pulls the latest components together and self updates on a by-build basis ensuring that you are always developing to the standards set out and defined by collective minds.

These components are a centralised resource that will be fed out to multiple projects ensuring that all developers are using the same standards, same tools and progression with the same overall vision set out. These same developers can also contribute back into the Toolkit by submitting suggestions and changes which are peer-reviewed and, if applicable, fed back into the master components – allowing other developers on other projects to update and receive the exact same improvements merged just moments earlier. Blinding, I know.

UI developers will be able to move from project to project in good faith, they will hit the ground running on familiar territory and be effective and productive from the get go instead of having to spend four weeks learning how to decipher three generations of a codebase passed from developer to developer.

There is nothing more soul destroying to a developer than entering a project and seeing no documentation, no bread trail or no clue as to what does why and what for. It may have started with the best of intentions but you can almost always pinpoint the exact point in which the developer gave up when you come across a function called something like “doSomething();”.

Every component will also have a ‘Styleguide’ – a master reference point for the developer to refer to when working on the project. These Styleguides will adhere to the best practices set out and allow the developer to copy and paste snippets of example code to use in their project. The Styleguides are also use the same components used to build the application so all the styling and code is 100% accurate to the project you are working.

The Build Tools

We have created automated build tasks designed to continually integrate changes that are made, whilst taking into account the developer’s working environment.

We use Gulp to automate every-day and unique project tasks that save serious amounts of debugging time, waiting time and time spent on development!

You save a javascript file: The file knows it has been changed, checks it for errors, runs unit tests where applicable and merges then minifies it, then reloads the browser you are working in to show the change.

You save a CSS/SASS file: Again it knows it has been changed, checks for errors, compiles then minifies it and reloads the browser.

You add new images to the image folder: It takes the images, compresses them and, if desired, creates a spritesheet automatically.

You need a cup of coffee: It detects this then… well, this bit doesn’t actually happen… yet.

These are just some small examples of what goes on under the hood of the build tools. If you can think of a task or issue that faces the front-end, there will be a 99.9999993% chance of being able to run an automated task to fulfill it saving development time once more.

The ‘White Label’

The ‘White Label’ refers to the starter project readily available for UI Developers to grab and get their project of the ground in one simple command. One command and you have 10 available example pages that follow best practices and guidelines. Examples would be:

  • Login/Register screens
  • Search page
  • Search results
  • Search item
  • News feed
  • News item
  • Notifications

All of these types of pages work against a dummy API to allow access to flesh out the UI according to wireframes provided by the UX process. The dummy API can also simply be switched out for the real thing once the backend comes into focus with no change to the structure of the application at all.

Effectively, what this means is that the whole application can be created against the same data structure that the back-end will provide, using the same ajax requests but against a set of development files instead. This benefits EVERYONE for obvious reasons. Feedback, understanding of data presentation, highlighting missing or incorrect data are just some examples.

As the UI Toolkit progresses, more variations of the ‘White Label’ will come to exist and when each one does, it will be on the best practices and guidelines available ensuring we always produce a consistent, clean and effective UI.


As you will have established – the UI Toolkit is all about automation. Consistency. Structure. Evolving. The current UI Toolkit is very much still in its youth but as it grows it will lead the way in UI Development. It will save huge amounts of development time, resource and become a recognised standard in which all projects should adhere to in order to fulfill its true potential.

We welcome any feedback or concerns as we strive to ensure the UI Toolkit is as robust and versatile as can possibly be and welcomed with open arms and not resentment and hostility. Leave a reply 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.