90 items found

Blog Posts (9)

  • Low-fidelity vs. high-fidelity prototypes - which to choose?

    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.

  • Discovery to Beta: putting users at the centre of the design for new digital services in education

    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.

  • My first steps into Software Engineering

    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.

View All

Pages (81)

  • Job Search | Solirius

    Job search Filters Job Type Contract Permanent Business Area Business Consulting Delivery Consulting Quality Engineering Software Engineering Technology Consulting Experience Level Entry Level Junior Intermediate Senior Lead Clear Showing 1-10 of 29 jobs Sort by: Sort by arrow&v .NET Automation Tester / SDET Quality Engineering Hybrid (2 Days PW Coventry) Permanent Intermediate ​ View Job .NET Consulting Lead Software Engineering Remote/London Permanent Lead ​ View Job .NET Developer Software Engineering Remote/London Permanent Intermediate ​ View Job Automation Tester / SDET Quality Engineering Remote/London Permanent Intermediate ​ View Job Business Analyst Business Consulting Remote Contract Intermediate End Date: 12/08/2022 View Job Business Analyst Business Consulting Remote/London Permanent Intermediate ​ View Job Data Analyst Software Engineering Remote/London Permanent Intermediate ​ View Job Data Consulting Lead Software Engineering Remote/London Permanent Lead ​ View Job Data Engineer Software Engineering Remote/London Permanent Intermediate ​ View Job Delivery Manager Delivery Consulting Remote/London Permanent Senior ​ View Job Delivery Manager Delivery Consulting Remote Contract Senior End Date: 12/08/2022 View Job DevOps Consulting Lead Software Engineering Remote/London Permanent Lead ​ View Job 2 1

  • Automation Tester / SDET | Solirius

    Automation Tester / SDET Business area: Quality Engineering Location: Remote/London Job type: Permanent Start date: Unspecified End date: N/A Security Clearance: Internal Background Check (DBS) Apply Return to Job Search Job description About us Solirius Consulting delivers technical consultancy and application delivery to our clients in order to solve real world problems and allow our clients to respond to an ever-changing technical landscape. We partner closely with our clients, embedding our consultants into their businesses in order to provide a bespoke service, allowing us to truly understand our clients’ needs. ​ It is this close collaboration with our clients that has enabled us to grow rapidly in recent years and will drive our ambitious future growth plans. We currently have over 250 consultants working with a variety of key clients from both the public and private sectors such as the Ministry of Justice, Department for Education, FCDOS, UEFA, International Olympic Committee and Mercedes Benz; with plans to increase our client base further in the near future. ​ We operate as a flat organisation and believe in trusting and supporting our team to operate independently. We pride ourselves on being specialists at what we do, making the most of our consultants’ expertise in their fields in order to provide a best-in-class service to our clients. All our consultants have the opportunity to work on a range of different projects, providing a broad range of knowledge on which to develop their careers and progress in the direction they choose. The role We are looking for experienced Automation Test Engineers / SDET to assist with leading projects with our clients from both the public and private sectors. You will have a testing background and be confident using your skills to run projects directly with clients with minimal supervision. You will be a fundamental member of the team, responsible for designing, developing and delivering test solutions whilst supporting and developing other members of the team and fostering best practice, keeping up to date with industry standards and advances. A Test Engineer is expected to have the following core skills: Experience of testing using Cypress with JavaScript. Experience of API testing with RestAssured Experience in working with developers to plan and design automation test frameworks and test suites. Automation skills at the service level valued more highly than UI level automation. Experience of working closely with the Ops team to help specify test environments. Experience in the following tools or similar: Cypress with JavaScript RestAssured / Spring test CodeceptJS Protractor + CucumberJS Mocha / Chai Puppeteer GitHub Jenkins And to be familiar with the following core technologies: Java/SpringBoot Express.js framework (Node.js) Angular Microservices & Azure cloud infrastructure Package and Benefits: Competitive salary, dependent on experience Flexible working / Work from home Generous annual discretionary bonus 25 days annual leave + bank holidays 10 days allocated development training per year Contributory pension Gym membership Annual away days and social events Equality and diversity Solirius Consulting is an equal opportunities employer. We are committed to creating a work environment that supports, celebrates, encourages and respects all individuals and in which all processes are based on merit, competence and business needs. We do not discriminate on the basis of race, religion, gender, sexuality, age, disability, ethnicity, marital status or any other protected characteristics. Should you require further assistance or require any reasonable adjustments be put in place to better support your application process, please do not hesitate to raise this with us. Apply hidden Related jobs No related jobs found.

  • Automation Tester / SDET - Apply | Solirius

    arrow&v Apply Return to Job Description Please fill in the required fields. Please fill in the required fields. Required fields are marked with a * Apply for Automation Tester / SDET First name should not be empty First name Last name should not be empty Last name Gender should not be empty Email should not be empty Email Phone number should not be empty Phone number Cover letter (optional) URL is invalid URL (optional) Portfolio, LinkedIn... (include https:// or http://) CV should be uploaded CV * Upload CV Please upload in .pdf format Privacy Policy should be ticked I have read and agree to the Privacy Policy. Apply Gender arrow&v Disclaimer: The personal information required in this form will not affect your application. We collect this information for data collection purposes only.

View All