Prototyping plays a vital role in the UX design process - but what is it? A prototype is a primitive version of a product, which UX teams use for testing before handing over the final designs to engineering teams for development. The aim of a prototype is to test and validate ideas by simulating a working product to improve its design. Prototypes allow for usability testing, communicating solutions to stakeholders, and to improve the quality of designs. Choosing the right fidelity Fidelity means how closely your prototype replicates the end state of the product. Before you begin prototyping, it is important to decide its fidelity. This will determine how much time and energy you will need to put into it. Choosing the right prototype comes down to choosing between high, medium and low fidelity. When deciding what level of fidelity is suitable for your prototype you will need to consider resources and skills, time, the audience, and what needs testing. About low-fidelity prototypes Low fidelity prototypes are sketches. They are used to test broad concepts and flows at the early stages of the design process, rather than the visual appearance of the product i.e. demonstrating barebones functionality without any aesthetic design. Paper prototyping is a common low-fidelity technique, where all you need to get started is a pen and paper. It’s useful when a product team needs to explore different ideas and refine designs quickly. These low-tech designs allow UX teams to visualise screen layouts, test navigation and experience user flows. Digital low-fidelity prototypes help UX teams organise information architecture and user flows before committing to mockups. Pros of low-fidelity prototypes: Easy and quick to make and iterate: a designer can quickly erase or change part of the design between (or during) test sessions Cheap: teams can test multiple variations and iterations at a low cost Catch potential problems early: low-fidelity prototypes put less pressure on users - they can feel more relaxed and express their views in more detail Low skill level needed: they only use simple lines and shapes, even non-design team members can provide valuable input. Validates ideas early: make it clear whether the concept of your project is clear to users Cons of low-fidelity prototypes: Limited learning: low fidelity prototypes do not provide meaningful feedback during usability testing Difficult to test: users might get distracted by the unfamiliarity of the product which may result in them focusing on the wrong elements Limited interactivity: It’s impossible to convey complex animations or transitions using this type of prototype About high-fidelity prototypes High-fidelity prototypes are used to assess flows and concepts, screen design and layout, data workflows, and interactions. They are highly functional and interactive, and as close as possible to the final product. They demonstrate functionality as well as the aesthetic look and feel of the product. The process involves choosing the prototyping tool, building the screens, and incorporating text, labels and interactions. Designers should only begin building high-fidelity prototypes after the low-fidelity prototypes have been thoroughly tested. High-fidelity prototypes should be in the last stages of the design process before handing over final designs to the development teams. Pros of high-fidelity prototypes: Allow for testing rich interactions: such as mapping Deep user insights: test participants are more likely to behave as if they are interacting with a real system, other than unnatural behaviours they may have when interacting with a sketchy prototype Testing of visual design: hi-fi prototypes allow for testing of specific UI components and graphical elements More presentable to stakeholders: Clients and team members will get a clear idea of how the product will look and work before it ever goes live Cons of high-fidelity prototypes: Learning curve required: prototyping tools can take time to learn Time-consuming and costly: ​​UX designers must spend more time making changes with greater detail, so high-fidelity prototypes cost more to produce Difficult to know when to stop: can be easy to get caught up in the minor detail In conclusion Focus on choosing the most effective method of prototyping based on your product’s needs and thoroughly test each prototype with its users. Low-fidelity prototypes are best used in the early stages of the design process to test concepts and user flows. Use high-fidelity prototypes when you are ready to gather more data on specific areas including content, interactions, and visual design.

The Education and Skills Funding Agency (ESFA), sponsored by the Department for Education (DfE), brings together the former responsibilities of the Education Funding Agency (EFA) and the Skills Funding Agency (SFA) to create a single agency accountable for funding the education and skills training for children, young people and adults. Aligning with the department’s data strategy The funding for educational institutions is delivered through various funding streams. The processes used to gather data for calculating the value and allocation of funds were time-consuming and complex. Teams had developed their own processes, on varying technology stacks, with limited consistency between teams. The production of datasets was one of the steps in the process to be digitally transformed, contributing to the department’s data strategy of reducing complexity and improving consistency. The objective of the Funding Data Service (FDS) project was to align the preparation of data with this strategy, whilst enhancing functionality from legacy technology solutions that were being decommissioned. Introducing agile ways of working - Discovery and Alpha For Discovery we deployed an agile multi-disciplinary team consisting of a user researcher, business analyst, service designer, data analyst and developer. In alpha the team adopted scrum methodologies and ceremonies (sprint planning, stand-ups, show and tells and retrospectives). A large amount of user research, business analysis and service design was needed during alpha. User research consisted of interviews, contextual enquiries and user surveys to help develop user personas and to map user journeys. Interviews were conducted with small focus groups, starting with single teams and then moving onto larger multi-team meetings. This helped encourage richer discussion and alignment between different groups. The business analysis covered stakeholder analysis, process mapping and backlog development. This work demonstrated that the service had a relatively small number of users, but the majority were experts in their discipline. Our focus, therefore, was to consume as much of their domain knowledge as possible and to ensure that we had a good understanding of their current pain points. “I always appreciated the FDS team following up on the feedback we provided as users because it felt like you were keen to build something that would work for us.” Choosing the right technology During alpha the technical team carried out data modelling, technical spikes and developed prototypes to prove our riskiest technical assumptions. For example, our first major technical challenge was to securely transfer data from a SQL server instance behind an internal firewall to cloud-hosted, MS Azure data storage. A technical spike was conducted to investigate the use of Azure services to do this, and desk research conducted to understand all relevant security frameworks. The technical stack consisted of: Front end: Angular 12, HTML, JavaScript, CSS Back end: .NET Core v5, microservices, Azure web services, Azure functions Data stores: SQL Server, Azure SQL server, Azure Blob storage, SQL SSIS packages, Azure Data Factory At the conclusion of alpha the team had: validated that a digital service would help resolve the problem identified the people and process change necessary for the new service agreed the tech stack and developed an approach for developing a Minimal Viable Service (MVS) for Beta. Developing the Minimal Viable Service The MVS would encompass a digital system for sourcing, managing and publishing provider data, including integrations with other digital services. This would deliver extensive value for the client and enable the decommissioning of legacy functionality. Using Scrum and working in 2 week sprints the team established a regular delivery cadence that supported dependency and risk management at a programme level. We adopted a behaviour driven development (BDD) approach across the team (development, quality assurance, analysis and design) to refine the understanding of user needs and pain-points. Early stage wireframes were iterated to hi-fidelity ‘development ready’ designs based on user feedback collected in design working sessions. User stories incorporated ‘gherkin syntax’ style acceptance criteria to give both the development and quality assurance teams a clear understanding of the expected user experience. The quality assurance team deployed an ‘automation first’ approach to testing, improving consistency, frequency and efficiency in test execution. Putting users first “I did feel like I wanted to put the extra effort in for FDS as it felt you listened to me as a user of the service and actually took on board what we wanted” Due to the seasonal nature of the user’s workload (peaks around term times), the timing of the MVS go-live date needed to coincide with the start of a new funding year to prevent operational disruption. Before the release of new functionality, the team conducted usability testing sessions with key users. This was critical to the product achieving user acceptance, and the feedback captured in a ‘near-live’ environment was analysed, refined and ultimately added to the product backlog as development ready user stories. The team worked closely with users in group and 1-to-1 settings, delivered regular ‘show and tell’ sessions with stakeholder groups including senior leadership, other digital services and potential future users. ‘Show and tells’ were used to drive a common understanding of the project’s progress and the service itself, and to capture input from a wider cohort. This helped to manage expectations and dependencies with other teams. Growing the service The goals were to deliver an MVS service that would meet user needs, deliver value, prevent operational disruption, and create the foundation for future scaling and enhancement. The MVS went live after 5 months of intensive work, supporting the delivery of £691 million in annual funding for 16-19 year olds. Following MVS the team have: transitioned to a hybrid live-support and development model, supporting day-to-day operations alongside the delivery of new functionality. released new functionality weekly, ensuring value is provided quickly and incrementally. onboarded new Funding Streams, meaning the service is now supporting the annual delivery of billions in education and skills funding. The team received excellent feedback throughout for their user-centred approach and were widely recognised as an exemplar for agile software development.

Anyone with little to no knowledge of coding should feel they can start a career in Software Engineering with Solirius. This is my experience starting as a Mathematics graduate. How I decided my future career During university Let me take you back to the month of September 2019. I had just started my second year of my Mathematics degree and the pressure of finding a graduate job was looming – especially since I had no idea what career I wanted to pursue! As most students do, I attended the university’s career fairs, collecting all the swag I could fit in my bag, then collecting more bags to fit more swag. While doing so, I visited stands from many different companies advertising jobs ranging from scientific research to agriculture. None of these struck me as the job I’d want to spend the next few years of my life in, so I continued focusing on my degree. As spring term began, an opportunity arose for a free web development course by Code First Girls. I hadn’t coded before, but the idea of making my own website lured me into applying. During the course, I learnt the basics of HTML, CSS, a small taster of JavaScript and GitHub. I was hooked. Seeing my one-line code changes make massive visible changes to the website (…not always as planned…) was incredibly exciting. But at this point, I saw web development as a hobby, since I didn’t know you could get a developer job without a computer science degree. After graduation Once my final exams were finished, I was able to resume my new thrilling web development hobby. I had plenty of time to explore coding, since I had no graduate job lined up, so I spent a few months creating a pretend ecommerce store with PHP following a Udemy course. Once I got to grips with the syntax, I realised that programming languages aren’t some alien code that only special translators can decipher. No, you can create something with just a few bits of ‘if/else’ logic and it will even read like a sentence when well-crafted. Here, I was beginning to consider that I could be a developer, but I would need some more experience before I knew for certain. I had a friend who studied computer science and said a great way to get into programming is by learning Unity, a game development platform boasting a codeless UI but with many options to add your own programming scripts. So, being an avid gamer, I jumped at the chance to design and create a game with this very friend. It was tough learning C#’s strict object-oriented principals alongside the Unity framework, though I began to fall in love with its design and knew that I wanted this in my life. Even though I was struggling with things like the syntax for creating a list variable, I felt I understood the features of the language and its potential enough to begin looking for a career. Applying to my first jobs I was instantly concerned that with no coding qualifications I would be at a disadvantage and no company would consider me. Not only that, but I was also still learning and worried that I didn’t know enough to pass any interviews. So, while I was signing up to (far too many) job sites, I also researched common technical interview questions such as “What is a hash set” and “When would you use a linked list over an array”. Strangely, I became fixated on perfecting the answer to “What happens when I type a URL in the browser and hit enter”, which I later found out was very popular in interviews. One day on LinkedIn, I chanced upon a job advert for a graduate software engineering role at Solirius, a consultancy company that is based in London… which I noticed was unusual because most consultancy companies demand you to be geographically flexible. “Agh, the advert is one day over the deadline!” … Still, determined not to miss an ideal opportunity, I hastily emailed Solirius a covering letter containing my CV. First interviews at Solirius Success! I had secured an initial phone call interview. I gathered this was primarily to check I was genuine about wanting the job, which I was, so it was successful. Following this, I learnt that the next stage was going to be a video interview. I was now very nervous – I had only done practice video interviews at university and for those we were given pointers on what the interviewers will be scoring us on. So, preparing like I did at university, I expected to be interviewed by a mark scheme. Within moments of starting my interview, however, I realised I was wrong. This mark scheme turned out to be a team of genuine people, who led the interview as more of an open discussion than a strict old-fashioned question-answer approach. This made me feel more relaxed, which in turn helped me talk about my ecommerce store and videogame projects I had worked on and what considerations I had while coding them. Final stages Having been successful so far, I faced the last two stages of my journey: a timed coding challenge and a technical video interview. Not long after finishing the challenge, I began to realise all the silly mistakes I had made followed by so many “I should’ve done this instead of this” thoughts… these tortured me right up until my last interview! So, as soon as the interview subject transferred to my code submission, I straightaway jumped at the opportunity to highlight my mistakes and how I would rectify them. This seemed to impress my interviewers, perhaps because it saved them the job of pointing them out! By this point, I had made it through a grand total of one initial phone call, one video interview, one coding challenge, and one technical video interview! I felt a sense of relief knowing that this journey was at an end, but that only spurred my desire to find out whether I had secured my first ever technical job. After what felt like a century – but was only about a week – I got a call from Solirius… and I was ecstatic. Why? Because my journey as a Software Engineer had just begun.

Growth Intelligence specialise in helping companies grow, using AI and uniquely rich SME data to drive more revenue, reduce acquisition costs and increase conversion rates. To support their business model Growth Intelligence were looking for assistance to: manage existing infrastructure and scale data pipelines to handle ever increasing amounts of data using contemporary cloud technologies create and maintain bespoke applications to support the day to day activities of their data science and customer success teams maintain code libraries, repos, apps and machine learning feature data. Setting up the specialist team Our specialised resourcing solution gives GI access to experienced, high quality data engineers at a wide variety of levels. Proponents of agile delivery, our team adopts GI’s hybrid scrum/kanban approach, monitoring sprint progress using kanban boards and running the full range of agile sprint ceremonies (daily stand-ups, retrospectives and sprint planning sessions). We collaborate with GI’s engineering and data scientists teams, using a stack of Python, Ansible, AWS, Tornado, Flask, Elasticsearch, Docker, Pandas. Working alongside the GI team and key stakeholders, our engineer’s work spans requirements gathering, technical spikes and OKR management. 2 years of success and growing Solirius has worked with Growth Intelligence for over 2 years and we are proud to continue our association, helping to maintain and improve the leading-edge services that GI provides to companies around the world. "The Solirius team are great additions to our engineering team. They are highly professional, effective at working independently (whilst also knowing when to seek clarification on requirements / design / architecture) and proactive in taking on projects / problem solving. They have integrated seamlessly into the team - which is great for us as a start-up as it enables us to have a single cohesive engineering team. They have a genuine interest in helping us succeed and creating a friendly and enjoyable culture to work in." Prashant Majmudar, CTO at Growth Intelligence

Inclusivity is at the heart of good service design. In this blog post Rebecca from our Business Consulting practice talks about what inclusive design is, why it’s important, methods to achieve inclusive design and how it can help you deliver a better service for users. Why is inclusive design important? Everyone involved in the design of a digital service, from software developers to product managers, is responsible for understanding the social impact of the products they deliver. Service designs that fail to understand the diverse range of user’s needs can cause unwelcome and costly problems later on, for example: Costly rectification work after go-live Increased customer support costs Customer dissatisfaction Brand degradation And in some circumstances… legal action. Inclusive design is about being aware of users of different abilities, genders, languages and cultures, and applying that understanding to your design decisions. The essentials for inclusive design So, where do you start? Build a diverse team Consciously or unconsciously, there is a tendency to assume that others have experiences similar to our own. Building a team with people from different cultural backgrounds, genders, abilities and experiences will improve self-awareness of unconscious bias, and lead to design solutions that address a broader range of user needs. This is equally applicable to small teams, even if you’re working on your own. Researching and reading about different experiences and inclusive design standards will help you discover new points of view and deliver a more inclusive solution. Design with users, rather than for users Conventional design tries to find the most direct route for the typical user, but is there really a typical user? In case you were wondering the answer to that is, no there isn’t. Denial of this brings risk. Inclusive design requires a shift in patterns of thinking. Designing with a diverse range of users from the start will help produce a design that better reflects your actual customer base. Examples of inclusive design techniques that often get overlooked Use of colours Colour theory goes a lot deeper than “pink is pretty”. Colours are used to elicit different emotional and cognitive responses and associations, often to convey brand identity and style. But, have you ever stopped and considered the needs of colour-blind users? Colour blindness affects approximately 1 in 12 men (8%) and 1 in 200 women in the world. In the UK this means that around 4.5% of the entire population suffer with colour blindness. Users who are colour-blind can mistake shades and/or be unable to distinguish between colours. How does inclusive design help us here? Don’t use colour as the only visual means of conveying information or action. Ensure there is a sufficient contrast ratio between foreground items, for example text or icons, and their background. Test your service using colour blindness simulation tools This example of an online booking form above does not provide enough contrast between the yellow and lime green colouring for a red-green colour-blind user to easily interact with. In the context of a booking form, a simple colour choice like this could lead to higher user dropout rates. Avoiding the use of jargon and complex language We can all think of examples of work jargon that we have grown accustomed (and immune) to, in our own industry bubbles. But, as soon as we step outside of it, we quickly realise it’s a bit meaningless and confusing for others. To break through this and create a more inclusive design, think about conducting a language audit with your users. This will help identify language choices that are unfamiliar or incomprehensible to others. The picture below helps to illustrate this: Graphics “A picture speaks a thousand words”. It’s a well worn phrase and is, therefore, easy to dismiss. For inclusive design, the choices we make for graphics represent low hanging fruit that can bring quick wins. Your service should represent the audience it’s speaking to. Duolingo successfully incorporates diversity in graphics. Their ethos is to bring people together through language, and their service reflects that. Working through the app’s exercises you are met with a diverse variety of characters – genders, races, ages, physical expression and even heights. The use of diverse imagery in its learning exercises is a great example of inclusive design that helps users to see part of themselves reflected in the service. Customisation Conventional design choices can lead us down the path of designing for the “perfect user journey” or “blue-sky” scenario. But does everybody really fit that profile? Customisation can be a useful inclusive tool that gives users the opportunity to tailor their experience according to their preferences. For example allowing users to customise their design and experience in settings. customise keyboard shortcuts for common actions customise sizing and styles enabling haptic feedback (haptic feedback is the use of touch to communicate with users, for example, the vibration of a mobile when you click on the incorrect option) Finishing thought Inclusive designs create a great user experience by considering a broad cross-section of perspectives and removing barriers. By creating a diverse team, involving users in the design, or by following inclusive best practice methods (preferably a combination of all three!), you will be well on the way to creating an amazing, inclusive service for all users.

What is the cloud? To the non tech-savvy person, what does ‘the cloud’ mean? When thinking of uploading files to the cloud, the common person does not care where that file goes, they think of that file as being up in the ether and accessible everywhere - stored away in thin air until its next called upon. What does this really mean? What is the cloud? And what actually happens when you upload a photo or your favourite song to the cloud? Well, in short, that file is being stored on someone else's computer (otherwise known as a server). This computer would typically be one of many belonging to a big company (think Amazon, Google and Microsoft) Here’s an example of a big cloud server farm. In this picture, racks upon racks of computers are used for ‘cloud’ purposes. So when you next upload a family photo to the ‘cloud’, you should be aware, you’re actually most likely just storing that picture on a computer, most likely belonging to a big tech company. Depending on the website you’re uploading the photo to, it could just as easily be a random stranger's computer. That random stranger will then be able to do what he likes with your family photo or whatever else you upload. This brings us onto what a website or web server actually is. What is a web server or website? A web server is someone’s computer. Even the computer you’re using right now, or even your phone, which is really just a mini computer, can be used to host a website. When starting as a web developer, you typically start by making a web application which runs ‘locally’. ‘Locally’ means that you are running it on your own computer. You can then see that website in your web browser (Chrome, Firefox etc.) But no one else can access and see your local site from their computer, so it’s not quite a website yet. How to host a simple website yourself? To run a website on your computer, a free downloadable tool like NGINX or Apache can be used. Even with a simple one page html file on your computer, you can run Apache and expose it to the internet. Then, anyone with the public IP address of your computer will be able to connect to it. Or if you buy a domain name, you can set that up so when they go to {insert your cool domain name here}.co.uk it will point to the web page being hosted on your computer! If you’re developing an app locally using a popular web programming language & framework (like python & Django, ruby & ruby on rails etc.) then NGINX or Apache2 can be configured to expose your app to the internet just as well! Why use a cloud provider or web hosting service? If your own computer can host a website then why would you pay someone else to host your website? Well first off, if you don't mind leaving your computer on full time then you could very well host it yourself but then there are other issues like security which could also have an effect on your decision. By opening up ports on your computer to the world, you’re also risking all your personal stuff on your own computer! For many people, the deciding factors are that your computer would need to handle the many requests made by people trying to look at your website and also would have to be kept turned on constantly. If it’s a hobby website which you’re not expecting many people to look at, that’s one thing. However, If you’re planning on this being a professional website expecting lots of users and traffic then your personal computer may very well not cut the mustard. For a professional site, it may very well need to scale to handle large amounts of traffic and requests. Even if, hypothetically, you had a really powerful computer at home, issues can happen which can cause it to go down. Power cuts, windows updates or even your partner unplugging your pc for her hair straighteners can cause unexpected downtime! This is where the latest cloud offerings can help. Cloud Offerings and EC2 Instances (AWS) Rather than using your own computer to host a website, you can rent an EC2 ‘instance’ (EC2 stands for Elastic Compute Cloud) from Amazon or similar from Google or Microsoft Azure. In essence, an EC2 instance is a computer (henceforth ‘instance’) which you can connect to and have power to do what you want with. In reality, although what you’re renting behaves and acts like a computer, it’s actually a ‘virtual machine’ which is really just using some of the resources of a computer. Or as techies call it: ‘compute capacity’ There are loads of options to configure that instance. If you want to run things on it which are very intensive, like processing videos or machine learning stuff then you can rent a much beefier instance or you can hire a ‘micro’ instance with the bare minimum needed to run a website. Similarly, depending on where your visitors are expected to be located you can rent the instance in a location of your choice. Amazon, for example, has server farms located all around the globe. Here’s a map of distributed instance locations around the world You can even commit to renting an instance for a longer period of time (e.g. 2 years or so) and get it cheaper (this is called a reserved instance). Or you can get it for dirt cheap using ‘spot’ instances. This is when you pay less for spare space on servers which hasn’t been hired at full price. This is similar to how shipping companies quite often use spare space in the haul on commercial planes. There is a risk with ‘spot’ instances though that your instance can be interrupted when that spare space is claimed. Alternatively, many companies actually offer free hosting too but these often come with a catch and don’t typically have the same level of service or quality of offerings that the big cloud providers (Amazon, Google, Microsoft) do. Serverless Now for the juicy stuff. There has recently been a bit of a hype in the ‘cloud’ world regarding ‘serverless’ computing. This has come about from the flexibility of compute capacity. Similarly to the Zipcar model of having and paying for a car just when you need it, you can pay for the resources running your website only when they’re needed (when someone visits the website). ‘Serverless’ is, as you might be thinking, a bit of a misnomer though as it would be a bit like calling Zipcar ‘car-less’. You are still renting the resources of a server but the crucial difference is that you’re only paying for it when it's needed. As expected, just as Zipcar is lots cheaper than paying for a car full time, serverless is way cheaper than renting a website full time. Serverless also allows you to avoid dealing with servers etc and focus purely on your app! AWS Fargate is one of the Amazon offerings which allows you to run your app serverlessly. (If you’re interested in how to do that technically, you’ll need to dockerize your app and put it on AWS first) From the perspective of someone visiting the website, the main difference is that it might take a couple of seconds longer to load the first page they’re looking at. Scaling your application - the need for multiple servers As mentioned before, having your website running on one computer, even if it’s one run by amazon etc, can have potential issues. If that computer goes down then so does your website. Similarly, as your business grows and you need to be able to handle lots more people looking at your website and making requests to it, you’ll either need a beefier server or, what is better practice, is to run your website across multiple servers. An illustration of the option between one beefier server or multiple smaller servers. (although, in this image, the potato may be the same as the many coins, in reality multiple servers are typically better suited to handling more traffic). Beefing up your server and adding more resources to it is known as scaling up (or vertical scaling). Adding more servers (or similar) is known as scaling outwards (or horizontal scaling). Horizontal scaling is especially important for businesses requiring minimal downtime or high availability! Many suppliers boast about the availability of their systems and in their SLAs (service level agreements), often commit to 99.9% availability! A multi-server environment can support more connections and services, helps to keep the system running, and can also cost significantly less each month than continually adding resources to a single server Load balancing So you want to run your website across multiple servers, how do you do it? This is where a load balancer comes in. The classic analogy for a load balancer is the waiter at a restaurant. In a small cafe, you might make the order straight to the cook. With a small website running on a single server, you’d make the request straight to the server. However, with a larger restaurant, in order to deal with more orders, there may be multiple chefs. The chefs aren’t going to take the orders straight from the customers, so instead you have a waiter who can take orders from the customers and distribute them amongst the chefs. This is the role of the load balancer, when you visit the website, it will direct your request to the server with the most capacity. As it says on the tin, it balances the load. Load balancers often have other duties too. They also typically check on the health of the servers and can also dynamically spin up or down servers as required to handle the traffic. Enabling your app to run across multiple servers A typical website makes use of a database. Databases are used just about everywhere including banks, retail, websites and warehouses. Banks use databases to keep track of customer accounts, balances and deposits. Retail stores can use databases to store prices, customer information, sales information and quantity on hand. Many websites also handle media. When you upload files to a website, they need to be stored somewhere. Think where do your pictures go when you upload them to Facebook? With a website running on one server, this can be quite simple, as you can run the database on that server and store the uploaded files directly on the server. But how would this work when you have a website running across multiple servers? The answer is quite simple, you alter your application to expect a remote database and to store files remotely. You would switch your application to use a remote database (e.g. AWS RDS) and you would also store those uploaded files etc somewhere else (somewhere off server where they can be accessed by the multiple servers -if using AWS, you would use AWS S3 - simple storage solution) So you end up with a setup like this where your application is running on multiple servers which are all accessing the database and media from a remote location There are a few other technical changes you need to make to the code in your app, including making it ‘stateless’ but this is just a quick overview of what you need to think about. A quick summary I hope this blog has given a helpful insight into what the cloud is and a rough overview of how many commercial websites are set up. There’s a lot more to it and plenty more configuration which can be used. E.g. with Netflix and Spotify, there are loads more technologies used for streaming and queuing songs/videos. And with big sites handling lots of lots of data, using the right technology for the job is essential to make things run quickly and efficiently. I’ve not gone into many of the technologies out there which are used on a daily basis by software engineers but this is intended to give you a basic but high level picture of what goes on behind the scenes when you go on your favourite websites.

Starting my graduate job in the midst of a pandemic was definitely not how I imagined my first job in the tech industry to pan out. But after nine months as a test engineer, it’s easily become one of the best decisions I’ve ever made! From already being exposed to three different projects as well as numerous internal business projects, the experiences, opportunities and knowledge I’ve gained is definitely unparalleled. To give you a bit of an insight into the role, I’ve put together a week in my life at work, hopefully to inspire others to join the industry and possibly even Solirius! Monday The start to the week is also the last day of the sprint! I’m currently on a project with the Department for Education which I only started on two weeks ago. As per Agile, this means we’ll be having a show & tell and a retrospective, both of which I look forward to. It’s nice to be able to show external stakeholders what we’ve achieved in the sprint and the retro is a great way to reflect, discuss what works, what doesn’t and ultimately, be better! I’ve also had some time to do a fair bit of testing today. I started off with some manual tickets since I’m still familiarising myself with the system but also picked up an automation ticket in the afternoon. For this, I used Cypress which is an automated UI testing tool which allows us to develop and execute scripts rather than running these manually. I had never used this before and so I faced a few challenges which I overcame by speaking to the senior QA and doing some research on Google. By the end, I learnt all about intercepting XHR requests and using the data as part of my tests and ended the day on a high; with me writing my first ever set of Cypress tests!! Beyond project work, I also did a bit of internal work today. First of all I became a buddy! All grads joining Solirius are assigned a buddy to help them settle in, this is the first time I’ve had the opportunity to do this for a new joiner and the first day has been great! I’m also part of the Diversity & Inclusivity team and in the afternoon, we had a meeting to discuss the results of a survey we used to get some ideas on how we can improve diversity and inclusivity within Solirius. We had some great responses which fuelled some significant discussions and we set up a Trello board to organise the actions we’ll be taking. Tuesday The morning began with me creating a pull request (PR) for my Cypress tests. This is a request which is sent to the technical team to review and merge code into the main code base. It’s always nice to get another set of eyes on your code, a lot of the time small mistakes which are not visible to you from working so closely on the code can be picked up. I then, as per any other day, joined stand-up where I got an update on how everyone else is doing as well as giving my update. I find stand-ups get me in the groove of the working day as they give me a clear indication of where we’re at and what still needs to be done. Today is also the first day of the new sprint which means that straight after stand-up, we had a sprint planning session where we decided what stories would go into the new sprint and made sure everyone understood them. After this, I had a stand-up for an internal task; communications and marketing, unlike project stand-ups, this happens once a week and is again a great opportunity to see what everyone has achieved in the last week and what the plans for the following week will be. Once I’d finished my morning meetings, I received review comments on the PR I had created with some great suggestions of improvements which I reviewed and started to implement to ensure the code met the required standards. Most of my day was spent on learning and improving the set of Cypress tests. In the midst of this, I also had two other meetings, one to set up my local environment for my project with the help of one of the software engineers on the team and a stand-up for another internal task I’m a part of; Sales and Bids training. I again, ended my day on a high by re-raising my PR which was approved and merged, always an accomplishing feeling!! Wednesday Halfway through the week! Today, I started my day off by looking at the sprint board and picking up any manual testing which was ready for QA. I always like to get manual testing out of the way in the morning so that I can have the day to code! Once I completed the manual tickets, I picked up an automation ticket and started to work on more Cypress tests. We also had a project meeting to discuss our ways of working, raise any concerns and highlight anything we felt was working well, specifically for how we work as a team as we’re a new team. Away from project work, I also attended a webinar this morning called “Breaking down barriers: How to inclusively hire, attract and onboard disabled talent”. It was a great experience and I managed to pick up loads of tips and tricks which we can look into utilising through the diversity and inclusivity team. This will help us ensure we’re giving all our potential employees the best possible experience when they go through the application process at Solirius. Today was also the monthly Solirius culture group which is an opportunity for the entire company to come together and discuss ideas on how to better ourselves as a company. Within this, we also have a monthly quiz which is great fun even though I always come last! Thursday More Cypress testing! Today, I picked up some more automation testing tickets and carried on working through and learning loads about Cypress. I also had a meeting with the team to talk about the QA process, as this project is fairly new, we’re still refining and perfecting our processes and ways of working. Overall, it was quite a positive meeting with some great action points which should help improve and automate our workflow. Beyond this, we also had a story refinement meeting today. These meetings happen once a week and are an opportunity to see and discuss the stories which are due to be bought into the next sprint. It always brings good clarity on the work we’ll be starting soon. Away from project work, I also worked on a ticket for sales and bids training just before our stand-up! Friday The end of the week is always an opportunity to wrap up our activities for the week! I spent most of the day having a deep dive into the backend of our project. It started with a meeting with the senior QA who took me through some framework he’s put in place to test the backend as well as explaining our different endpoints and what they do. After this meeting, I did some further exploratory testing and had a play around (on my local environment) to familiarise myself with how everything is pieced together. I then ended my day by having a catch-up with my buddy to see how he was settling in as well as just having a chat! I then also had a catch-up with my line manager, we usually have these once a month and it’s always great. We get to spend some time discussing how I’ve been getting on, what I’ve been learning, any concerns I have and making sure I’m enjoying what I’m doing; which I always am! The week has flown by and in my role as a test engineer at the Department for Education and as a consultant at Solirius I have accomplished many tasks and learnt numerous new skills. Some of my key highlights of the week include: Installing and setting up Cypress Writing my first set of Cypress tests in TypeScript Raising and merging my first PR on the project Identifying and working on the improvements we can make in our ways of working Looking into the backend Attending the webinar and bringing some key action points to the Diversity and Inclusivity team Working on some sales and bids training tickets Having an introduction with my new buddy and helping him settle into Solirius Catching up with my line manager No two weeks in the role are ever the same, therefore, I’m sure the next week will be very different but just as exciting with many more lessons and technologies to learn!

My motivation for the role Since becoming a software developer with Solirius a year and a half ago, I’ve worked within several teams, all with different ways of working. I’ve gained experience in operating within both scrum and kanban frameworks, attended and participated in a variety of agile ceremonies and practiced different agile techniques. I’ve found that as a developer, sometimes you follow ways of working and agile principles without necessarily knowing why you are doing it. I decided, as part of my career development, that I wanted to further understand how a complete agile environment is created, the difficulties and intricacies that are a part of creating this environment, as well as the reasons behind certain agile practices I was following. To help me do this, I was asked to act as a scrum master to the graduates who had recently joined Solirius for their fortnight-long training. I thought this would be a great way to improve my understanding on all things agile and to see delivery from a different point of view. Overview of the project The graduates taking the training were developing a full stack web app, and whilst each team member created their own app, the aim was for them to collaborate and learn together. My role, as the scrum master, was to create the agile ways of working, facilitate the agile ceremonies as well as connecting team members with others for help, and support team members to find solutions to any problems they encountered. To structure the scrum process, I used the agile ceremonies that had been used by the previous scrum master for the last graduate training, these were daily stand-ups, a show and tell and a retrospective. I used my own experience, from participating in my development teams’ ceremonies to run them and adjusted them to be appropriate for the graduate training – an example of this is that in the retro I decided to have two retro boards, one for the team to reflect on their own work, and another to give feedback on the training that they were given, including the agile process that I had set in place. Before starting the project, I was excited about being a scrum master – I wanted to see first-hand how different agile techniques can change outcomes of work. However, this was also my main concern about taking on this role. I knew that the delivery of the team’s work would be directly affected by the scrum and agile processes that I set in place. At the end of the project my experience was very positive. As a software developer I have always been protected within the team, this has often been from the delivery team both resolving external issues that could have an impact on development, and guiding the team to decide on realistic sprint goals, in order to not overpromise. Moving to the delivery side of this, being a scrum master felt like a much more exposed role with a lot more accountability. Further to this, prompting conversations and checking in on team members and facilitating the scrum ceremonies ultimately made it my responsibility for both running things smoothly and ensuring agile working was stuck to. It was important to ask the right questions during the sprint ceremonies to ensure that the team members had a clear understanding of their sprint goal and were working effectively towards it. My main difficulty was learning when to step away from the team and let the team do things themselves. When the team members started to self-organise and sort tasks between themselves, I had to realise that this was actually a good reflection of my guidance, rather than the opposite. Key takeaways and future opportunities The lessons I learnt, from acting as a scrum master, are transferable to my role as a developer. My understanding of the definition of a scrum master has been consolidated – a scrum master is there to establish and maintain the scrum process, and protect the team from blockers outside the team. From this I’ve gained a greater appreciation as to how difficult it is to create this effective environment for the team. It has also highlighted to me the importance of good communication to the delivery team and reminded me to always voice the blockers I’m facing. I also think I’m now more likely to discuss the agile techniques I’m using with my scrum master, so that I fully understand why I am working a certain way. Whilst I still enjoy development work, in the future, I will look for an opportunity to work as a scrum master for a longer period of time, as I feel like this would further increase my understanding of agile. Having the opportunity to work with a team for several sprints would enable me to implement improvements, highlighted at Show and Tells and Retrospectives, into future sprints. This is a particularly important next step for me in my learning as iteration and constant improvement are key principles in agile. I would also love to be able to incorporate other ceremonies such as sprint planning, and to introduce techniques like having a definition of done and creating burn-down charts. These are things I do in my current development project, and it would be helpful to see the delivery side of them. I believe every member of an agile team would find having a good understanding of agile methodologies and practices beneficial to their work. Understanding your ways of working, and using agile techniques effectively helps you to be a part of a strong, efficient team. I also believe that knowing why you are working a certain way helps you to feel more connected and rooted in your work. A great way to do this is through training. As part of the graduate onboarding, Solirius gives an introduction to agile training, this is a great foundation to then build on with experience from project work. Solirius also offers Advanced Agile training, which has been made specifically for Solirius consultants who are looking to increase their understanding of agile even further and is something that I’m looking forward to taking in the next few months.

In June 2021 I was not only excited about the prospect of lockdown measures being lifted but I also was due to start my new job at Solirius as a graduate in the Business Consulting Practice! Although the world seemed to be slowly going back to ‘normal’, Solirius, like many other companies, was still operating on a remote basis to keep everyone as safe as possible. So as strange as it was, I received my onboarding pack and laptop in the mail and my first day began from the comfort of my own home. Everyone was so welcoming over Google Hangouts and Slack, and my first week at the company was filled with introductory calls and some preliminary training. One thing I learnt and loved about Solirius during the hiring process was that they believe that learning by doing is the best way, and because of this I was assigned to my first project during my very first week! 3 months down the road, I am about to finish my time on my first project before I get stuck into 2 weeks of internal consultancy training. In this blog post I will take you through a standard week in the life of a Business Consulting Graduate on their first project with Solirius Consulting. For a bit of background, my first project is for a government department where I was working as a Project Support Officer. As I expressed interest in both project management and business analysis during my interview process, my first role became a hybrid in which I supported both elements. Monday The week in which I’m writing this post, comes during a planning period of the project. We are currently planning our deliverables for our next phase which involves a variety of workshops internally with the team and with the client. On Monday we had a meeting with our technical team to decide how much we could deliver in the phase, broke down each item and worked out the acceptance criteria. This is an important part of any project, as you need to make sure what you are delivering aligns with your clients’ wants and needs. Monday is also our weekly working group with the project sponsor. During this 1 hour session we give updates on the work completed over the last week, highlight any issues and discuss important queries. Tuesday On Tuesday I got to work on more of the project management side of my role. We had a meeting with the finance team to track our spending, making sure we are within budget, and outlined our planned expenditure for the coming months. We also had our fortnightly meeting with the assignment management team to go over our payment deliverable report. During this meeting we report and give evidence on our progress vs what we had promised to deliver in our Statement of Work. This evidence is an important part of the commercial process. On Tuesdays I also have my catch-up with my managers where we talk about how I am getting on, and if there is anything they or I can do to improve my work on my project. Although at Solirius your main focus is on client work, my manager also takes this time to encourage me to work on internal projects, which can range from writing a blog post like this one, to helping fix bugs on our internal time tracking system. Wednesday Every Wednesday morning I run my own meeting and manage my own aspect of the project. This meeting is to update our Project Control Log which documents all the risks, actions, dependencies and decisions of your project. This is a very important document that regularly gets presented to senior stakeholders. I love that although I am early on in my career I am trusted enough to be given this responsibility. Another exciting part of this Wednesday was the Culture Group meeting that happens monthly for Solirius employees. It is a chance to meet people from across the organisation, hear updates such as when we were due to go back into the office and take part in a quiz. Thursday Although I started the job at home, we are now able to book days to work in the Solirius office in Aldgate. This gives you an opportunity to meet colleagues from the company and get a change of scene! On Thursday I decided to spend the day at the office and work more on the business analysis side of my role. We ran a workshop with the data scientists on the client side in order to identify what their requirements were for the tools they need to do their day job. After a workshop like this, time is spent documenting user stories, creating user story boards and ultimately converting them into ‘tickets’ of work for the developers to do. Another benefit of working in the office is being able to grab a drink with colleagues after work and get the real experience of working in ‘the City’ (our office is practically next door to the Gherkin and the Cheese Grater!) Friday As the week winds down on a Friday, my project manager and I have another report to prepare for our client. This report again documents our progress towards our milestones, gives any updates to specific risks or issues and gives these stakeholders a view of our project. Fridays are also when we have our fortnightly retrospective meeting. In an Agile project, you hold retrospectives at the end of each sprint to discuss what went well and what could be improved on. It’s great to get the team together to talk about our wins and mentally prepare for the next couple of weeks of work!