With the latest developments in our UX project-handling, we're now sharing some details!

Magda is the project manager with a knack for some UX/UI design. She’s had a chance to work with many of our clients as well as participating in the creation of our website, which made her well-acquainted with the world of eMobility.

Magdalena Betlińska

At Solidstudio, we like to keep things transparent and so, we thought it would be a good idea to share some more information about our UX process within the projects with our clients. As much as eMobility solutions are the main core of most of most of our publications and general communication, we’d like to break it down with some insights on how we work within the dev projects.

We know the importance of good UX but we’re also well aware that some may pay more or less attention to it than others. With that in mind, our UX process has been constructed in such a way as to serve both approaches.

Generally speaking, we put a lot of care into grasping what is the desired outcome and we’re trying to engage our customers into taking an active part in the creation of mockups and final UI.

Such approach serves a couple of goals, some of them being:

Transparency with our customers in regards to the UX process (not only final mock-ups)

Possibility of better price estimation during sales process

Environment optimized for designers working on a product concept (which translates into product quality)

The way we create and lead the UX within the projects can be narrowed down to 6 steps. Each of which plays a huge role in the success of the final delivery. Below, we’ll try to break them down a bit.


The kick-off of the UX workload starts with a thorough understanding of what it is that's to be made. This is where our team carefully goes through all the materials delivered by the client, analyses them and, if there’s a need, asks any necessary questions on an entry level.

This is also the time to look for the current trends, solutions implemented by others, some of the best practices and the general state of the matter as it stands on the market.

Such an in-depth analysis & research allows our designers to draw valuable conclusions and become familiar with whatever the project is.

thorough analysis of the customer’s needs

acquiring all the necessary information to kick off the project

The concluding part would be the presentation summing up what has been gathered presented to the client.

After initial analysis, the next step contains the customer workshops and whatever it takes to get them ready.

It starts with preparing all the materials necessary for a successful workshop. We prepare the Miro tables and tutorials that are to be presented to the client. Our designers and PM also figure out the agenda of the meeting in such a way as to present everything that has been established so far in the most attractive way.

The actual workshop with clients involves event stormings and user story mapping, all discussed with the clients and open for any necessary alterations.

The outcomes of this steps are as follows:

Gathering all the materials including the Miro tables

An initial walkthrough with PMs, designers and the clients

Event storming and a space for discussion

After the workshops are complete, the client gets an executive summary and previews on the project.

It might be said that this is where the actual UX work kicks in. This step is all about starting to establish the actual product and how it’s supposed to be created.

One of the main points here is determining and describing the user-flows - which is nothing short of the path of clicking it takes for someone to trigger the desired action i.e. on a mobile app. Once this is settled, the next issues on the conceptualization agenda are to create the information architecture.

This is also where the first low-fi schemes are being created.

information architecture (to be confirmed with the clients)

It must be mentioned that the work done on product’s conceptual architecture is being communicated to the client and put forward for reviews.

Based on the outcomes from the previous steps, with the wireframing we start to develop a much more advanced product.

With this step, the low-fi models are being created (in black and white for the starters). This is also where we create the clickable prototype in Figma.

The client then gets an advanced visualization to be checked. Later on, based on any feedback, our team takes time to implement any changes (if such are desired).

As much as the list of outcomes in this step is not to extensive, these are all crucial in the final design process:

Worth underlining is that with this step we require our customers to provide us with a green light in order to go further.

Despite what some people may think, the proper design only starts here, after all the above are finished and accepted.

This step includes the look&feel project. That is, the presentation of what the design is supposed to look like in terms of colors, brightness, shapes or the use of pictures and illustrations. We also prepare the moodboards that are to be shown to the customers.

Finally this step includes the UI design and the preparing of style guides for the developers.

It might be said, that here’s where the most crucial work in terms of the actual design happens, among the outcomes there are:

In this step, the client gets to see the product as it is supposed to look like in the final version. A meeting is being held to discuss the product and possibly make some final amendments.

This would be the final part and most probably the most self-explanatory.

It’s the time to run some usability testings and consult any possibilities with the developers, if needed. It’s pretty much all about the final reviews and some last minute minor changes.

Generally, it serves the purpose of making sure everything run smoothly and works in an agreed manner.

As stated before, we value a good UX as much as we value transparency with our clients. A good design is one of the key factors in creating a successful project. Well-done UX can make the difference between a user enjoying using your product or service, and a user becoming frustrated and giving up.

The offered process takes into consideration both parties, the client and the end-user equally and allows us to deliver the best solutions satisfying to all.

We would also like to point out that we’re open to any discussion and alterations in case any client believes it would suit them best. Should anyone has any questions, we’re more than happy to answer them!

Learn more about how we work! With the latest developments in our UX project-handling, we're now sharing some details!

eRoaming Hubs explained

Trust is a must. Especially in running e-mobility business. Here is why.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

Having spent over two years developing various components for one of our e-mobility partners I want to share some insights on how to cope with challenges, what to expect from IT partners when developing e-mobility components and how testing various approaches can lead you to some of the breakthroughs.

Before you start, whether you are an aspiring Charge Point Operator or e-Mobility Service Provider, here you can find some valid questions, worth answering: Is there a ready-to-apply business model for long-term prosperity in the e-mobility segment? What return could be expected for now and in the future? What in-house skills are needed and what other partners require for revenue growth? Could technology and data analytics enable the business to provide ‘smart’ solutions? If yes, how? Where is the industry heading to and what are long-term goals?

What we face now, in the era of uncertainty, is another ‘revolution’ dictated by the exhaustion of fossil fuel resources, environmental pollution, and hence the transition to green energy. The EV market, especially in Europe, is growing fast and we face the increasing need for accessible, charging infrastructure, green energy demand, and a change in consumers’ behavior. With a rapidly rising demand for investment, we have a common ground - require a change in consumer habits. Even with rapid-charging technology (50kW+), charge time takes 20 to 30 minutes to reach 80% of battery capacity. But a well-known benchmark - refueling petrol or diesel experience is still out of reach. It seems that there is still a long way to go to achieve full flow, yet without constant development and improvement of the accessible infrastructure, we won't be able to move forward. Providing consumers the multitasking opportunity for rapid EV charging, whether combined with retail sites or bespoke charging 'lounges', together with a shift from a top-up (as opposed to refuel) mentality will be necessary to aid mass adoption.

Below you can find some thoughts on obstacles you may find while developing an e-mobility platform, what to take into consideration while creating a workflow, and what to expect when you start your venture into unexplored areas.

Creating a valid data model from the beginning will be a huge time-saver

Late changes to the data model are time-consuming. MVP or initial variants of the software cover all the basics. When the system does not require a sophisticated model of the charging infrastructure it may be enough to shape the whole charge point as a flat structure. Upon this simple model, more features can be built, till your range grows, and a need to open the platform using some open standard comes up. This action requires mapping development between the internal model and the one introduced by the standard. If the existing model does not support concepts (e.g. Location and Evse) and does not follow general standards, when it comes to the format of IDs, it might demand plenty of work to perform the efficient mapping.

While working for one of our partners, mapping their existing codebase to make it available for open standards, for a team of developers took several months. In fact, if the model would match the standard from the beginning, the integration would require just a simple action, and full integration would be possible within a few weeks.

Lesson learned from this experience: The time for full integration can be significantly boosted (reducing a few months of integration to a few weeks) thanks to the implementation of a ready-made code sequence linking the standard and the platform. Once the standard is properly applied, further action will become smooth and easy.

Creating an efficient architecture of the system from the start prevents many bad decisions

Some aspects of system architecture are specific to the domain. For example:

deciding which processes are synchronous and which are asynchronous

the decision of whether or not some data must be immutable

Understanding incremental improvements and having in mind that not every single aspect can be predicted is crucial. However, knowing the domain certain aspects can be included early in the design process.

Lesson learned from this experience: General concepts, but taking into account these limitations from the very beginning helps to avoid making wrong decisions when designing and developing the e-mobility platform.

Knowing the details of adopted standards is the shortest way to success

OCPI is defined as an open standard. In theory, everyone ought to introduce this standard in the same way.

Lesson learned from this experience: OCPI is not always the norm. Hub Gireve, for example, extends this standard. Some concepts exist and are not part of the OCPI documentation. Some OCPI partners require a certain sequence of specific actions that are actually not part of the standard. It is worth knowing this upfront when designing the CPO/eMSP end system.

The domain knowledge provides you with solving individual cases

Having the domain knowledge within the development team allows participating in specific direct business conversations about e-mobility. Becoming familiar with general concepts, e-mobility background (CPO, eMSP/EMP, EVSE, eMI3 ID, OCPI, OICP, OCPP), ubiquitous language, different market approaches (public/private/fleet charge points), we can immediately proceed directly with the specific business issues that are to be done, rather than technical details (as a reliable tech partner we already know them).

Lesson learned from this experience: We have learned that getting to know a specific area takes time, but once explored, it allows us to catch common parts. The observations turned into concrete e-mobility solutions, thus are an improvement for the future. Combining domain knowledge with high-level technical skills provides quick integration and unlocks business processes.

It might sound a bit cliche, but without having great, skilled, and curious minds on board I cannot say that the progress we witnessed would be possible.

Lesson learned from this experience: In addition to specific technical skills, in such projects where many questions are asked and actions require a constant search for efficient e-mobility solutions, the spirit of a truly matched team of individuals appears.

Knowing the challenges from the scratch, making observations, and drawing conclusions for the future on how we could boost integration, we have spent a couple of weeks developing ready-to-integrate components for Open Standards. Full e-roaming is possible to achieve faster.

 – The component being an Anti Corruption Layer between any CPO/eMSP system and any OCPI partner (hub like Gireve and p2p partners like other CPOs and eMSPs). The component has the whole OCPI registration process modeled with the token-based security mechanism. It maps all OCPI calls to the internal backend API (this part is open for modification for the concrete backend system).

 – The component and test suite allowing to execute e2e tests of the platform using OCPI protocol. Testing OCPI allows a complete test of bidirectional processes that are part of OCPI.

 – The component is an OCPP server being able to connect to the charge point using OCPP (2.0.1) protocol. It is a proxy for the whole communication between the charge point and the CPO backend system.

 – The component is a software Charge Point that allows e2e testing and monitoring of the CPO platform.

Soon our work will be done with this extra e-mobility component:

When life gives you lemons… it is up to you whether you choose to make a lemonade or order the lobster tail. If you have any concerns while developing your e-mobility platform, need advice, or wonder which directions to take when setting up your next goals feel free to reach out. Here you can find some experience and knowledge, as well as ready-to-implement e-mobility solutions.

e-Mobility partnership – lessons worth to know

Anchor points on becoming Charge Point Operator. Click to learn more.

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

The e-mobility market is booming but still enigmatic in terms of processes between market participants or taken roles and available standards. In general, we can distinguish two sides of the charging ecosystem - being on the user-side eMobility Service Providers and Charge Point Operators providing devices and software to manage the infrastructure. In this piece, we address the part of the market responsible for deploying and managing charging points (also called charging stations).

Charge Point Operator or Charging Station Operator is responsible for providing, managing, and setting the charging infrastructure for the e-mobility industry. A CPO business operates a network of charging points - the hardware devices and future-oriented software. The value lies in connecting smart charging equipment with eMobility Service Providers. A CPO assures the network works seamlessly. This includes diagnostics, maintenance, price setting, and Point of interest (POI) data management.

On the operators' side is to provide available, steady, and 24/7 functioning EV chargers. Managing systems need to real-time report any malfunction that occurs with the device. And if possible, automatically fix it.

The matter of real-time also applies to software platforms. Necessary information delivery for adequate decision-making will help to shape operations, business, and technical statistics analysis. Even when the service does not assume the large scale, automation is the core in reducing the Total Cost of Ownership (TCO). Automated processes should hassle-freely handle transactional and technical concerns without engaging employees.

Charging Stations require sufficient energy supply and distribution. Smart management during peak hours, involving renewables and storing battery power, reduces capital and operating costs. Identifying areas for cost optimization and investigating user’s expectations will help balance business processes. This market will continue to grow, for now, with a focus on segmentation, preferences, and habits, the hidden (greener) Holy Grail is possibly up to grasp.

How does the Charge Point Operator platform work?

First, we need to explain that an Operator’s role range may vary. In some cases, CPO owns the infrastructure, provides connectivity, and can supply only one side of the ecosystem. Some of the CPOs act like 

 . Since it’s a mutual interest, they offer other eMSPs access to the charging infrastructure.

To explain the charging ecosystem’s general flow, let’s place CPO as a separate service - hardware and software provider. In this scenario, CPO exposes access to the charging network and relies on eMSPs.

CPO exposes charging network with tailored API. In this scenario, each new linking with a partner follows the provided documentation and matches eMSPs API. This approach is time-consuming and limiting in terms of fast integration and scaling. Via custom API, we link two models and two teams working separately. The matter lies in the charging options provided, and the service eMSP wants to offer. The integration via custom API takes months. Assuming that each operator offers only integration via its API, connecting with each requires substantial resources and time.

However, there are two faster ways to connect and open the charging network.

 follow the general principle in the e-mobility world, providing an open and accessible network to EV drivers. Charge Point Operator can expose charging network to any eMSP in a standardized way, enabling faster integration and scaling. With Open Charge Point Interface (OCPI), managed by 

 , the linking between partners can be done within several days. Open Standards, besides, provide transparent information to consumers about charging locations and prices. Moreover, they are developed and updated by a strong community 

following technical innovations and market requirements

 . Also, as a part of the ultimate goal, Open Standards are free to use. By simplifying, standardizing, and harmonizing charging networks, standards are an integral part of rapid e-mobility growth.

With one contract owned Charging Stations become exposed to thousands of new users and eMobility Service Providers. Thanks to the Open Intercharge Protocol (OICP), integration with a hub like GIREVE or Hubject opens the broadest spectrum of possibilities. E-roaming networks are the desired state of EV charging cross-border arrangement.

Being integrated with a hub does not limit the other possibilities. Charge Point Operator’s platform can be exposed at the same time to the hub, and eMobility Service Provider via the most commonly applied (and supported) OCPI standard.

What are the Charge Point Operator platform’s features?

At the most basic level, every Charge Point Operator platform should provide via admin panel pricing, reporting and billing solution, remote charging stations management, and smart energy management.

The comprehensive backend system allows CPO to 

 for the charging session. Rates can be modeled and verified at the admin panel. The charging session’s price can be specified on the total charged kilowatt-hours, the duration, or a blend of other circumstances (additional parking fee, time & day of the week). The B2B contract between CPO and eMSP includes all tariffs and is invoiced at the end of the billing period. The price that is exposed to the final user (EV owner) depends on the individual eMSP price management system.

, CPOs should easily handle all station-related administration and control tasks. The admin panel should provide a view of the billing history, modify charging prices, remote management of chargers, and with advanced automation resolve common issues.

 allows to reduce the risks of the station and network overload, ensure EVs are charged securely and economically optimized. The highest charging switch can be limited from the admin panel. For example, developing a feature for dynamic load management (DLM) allows setting maximum capacity for several charging points and diffuses the load within the single one.

How can Charge Point Operators optimize their business?

Focus on operational advantage, staying up-to-date with the most recent protocols’ releases, smart energy administration, monitoring, and analyzing will provide excellent scalability and interoperability. The reliable charging infrastructure management system, easy to maintain and open for eMSPs boosts network scaling and ROI. In turn, an e-roaming platform exposes charge points in the fastest and most efficient way. Fortunately, one approach does not eliminate the possibility of benefiting from the other. However, responsibility for the maintenance of charging points remains on the CPO's side. Automation and the ability to make quick, ideally remote fixes, responsiveness will have a significant role in the prosperity of one's performance.

Direct and indirect recipients of CPO services depend on the availability of the entire operational infrastructure. This includes real-time hardware monitoring to identify and fix malfunctions before the beneficiary - or even the CPO - is aware of them. Automated maintenance reduces costs of in-field technical repairs.

It’s good to make sure the CPO platform offers smart energy management control. The entire energy flow across the EV charging system secures energy that is delivered at the right time to the right stock at the lowest cost.

The ability to scale is critical to keep up with the booming growth of the EV market. It’s not just about placing devices in an accessible locality but also about providing back-end infrastructure ready to connect with new partners and render the service.

For long-term operations, interoperability will be essential. On the CPO side lies the responsibility for delivering the 

 , allowing easy integration of any charger. Compatibility with protocols and standards like OCPP, OCPI, OICP secures smooth backend operations’ communications.

When considering investing in Charging Infrastructure, the above issues are worth verifying whether the available solutions on the market meet our expectations. Depending on the scale of the planned activity, our needs will differ.

How to efficiently manage interoperability?

Charge Point Operators are the foundation of the eMobility growth. Analyzing and improving EV charging operations leads to better decision-making. In consequence, it maximizes business profits and eliminates unnecessary costs ensuring the best EV charging experience. Regarding investments, this varies based on which market we plan to operate in. Both governmental plans and local units support the development of charging networks. Thus it is worth spending time and finding out what are the possibilities and criteria for obtaining subsidies. The shape of the budget may be subject to modification, and new approaches may arise.

With the advantage of having e-mobility experts, at Solidstudio we took on board the daring challenge of developing a CPO platform on our own. Knowing the industry's nuances, we made sure that the product we developed would suit a whole plethora of needs that various clients may search for. Thus, our CPO platform can be installed either in any client’s infrastructure or as supported by Solidstudio.

Our platform comes with various necessary functionalities that concur to an effortless charging stations management. The core features consist of:

There are more functionalities planned, they will be gradually announced.

 is fully customizable, ready to be designed as per client’s requests. Supplementary features (which are not within the license, such as the new standards implementation) can be available to purchase as an add-on or upgrade.

How to become Charge Point Operator and manage the CPO platform?

Pro tips how to overcome common Progressive Web Application challenges

Being a co-founder of Solidstudio, Paweł has got to see all the development phases. He’s a skilled professional with years of experience, both in the software and in the eMobility worlds.

Paweł Głogowski

Common challenges with PWA can be fixed in a variety of ways. In this article, I want to share some practical tips and solutions on how to resolve common issues of Progressive Web Applications. Refreshing, service-worker configuration and updating to save time and achieve smooth flow and be ahead of your users' needs.

This is the second part of our series about PWA. If you’d like to learn how to change your web page into a Progressive Web Application, be sure to check out our previous 

 application that can be served as a Progressive Web Application. We follow a 

 approach to enable quite frequent changes in the product and ensure that our users get the latest content of the application.

 is heavily cached, serving the latest content to users can be challenging. It’s not possible to refresh the application when you’re in standalone mode so we have to do it differently. We spent some time preparing a user-friendly solution that would allow users to get the latest version of the application quickly.

Different ways to refresh your application

Developers can approach the problem of refreshing the application in different ways. 

The easiest way could be adding a fixed refresh button that is available only on the 

 version. It might be the easiest way since it doesn’t require any interaction with service workers. However, it’s not very user-friendly. Users may not be aware that the latest version of the application is already available and ignore that button.

The second approach could be informing users when the application is showing on the screen. So once the new version is available, users will see some indicator bar with a refresh button. That way, they will know that there’s new content to fetch from a server. Let’s take a look at how that’s indicator bar could look like.

We can achieve the above effect by using 

. Take a look at the following code to see how to achieve it. To get the best result, you should show this bar only to users in a standalone mode (PWA) - we discuss this in our previous article (link) so make sure that you generate that bar only in standalone mode. Additionally, you can style your snack bar to suit your application best.

You can see two handlers in above code - let's see how they can looks like:

We don’t want to allow refreshing the application because we notice some unexpected behavior on iOS - it tends to fail randomly or behaves in an unstable way after some refreshing, so we encourage users to kill the app and reopen it. However, refreshing seems to be stable on Android and Chrome, so for Chrome users, you can change the bar and show the refresh icon so users can refresh the app to get new content on their own.

From the programmatic perspective, nothing interesting is done here - we just show a bar and allow the user to close it. The more important thing here is how we indicate that a new version of the application is available to the user. To do that, we need to define a proper callback for updating service workers and force them to be updated. More on that in the next part of the article.

How to update Custom Service worker callback?

Let's take a look at the service-worker configuration generated during the development of a React application.

I have highlighted the most important parts of that code snippet. As you can see, we add a listener on the state change of service worker. It will be executed when changes occur in the service-worker. It might be misleading that we’re watching for the ‘installed’ state. But the existence of the controller property indicates changes in the service worker. What we need to do is to pass the config object with the callback onUpdate function. We usually need to register our service worker in the index.js file. Here we pass the object with the onUpdate property which is a callback function.

Making your application usable in case of the lack of an internet connection isn't going to be a part of this article. Instead, we will focus on enabling users to install your application for both iOS and Android applications.

How to skip waiting for a new service worker?

However, it's not enough for the configuration of service worker. Because we want the new service worker to take over the old one immediately, we need to configure it to skip waiting. If we don’t do this, the new service worker will be available after the user navigates the refresh current page. It's not always an option since we observe some major problems with refreshing the page in the PWA mode. Visit the following 

 to understand the service worker lifecycle better.

To configure the service worker to skip waiting, we need to add some code to the default service worker implementation which is provided when we generate a sample project. To do so, we will use a tool called 

. So we first need to add a proper dependency to the package.json file along with the modification of the build command. It should look like this:

Note: The following example is valid for React application, but it will look quite similar for application build in other technologies.

You need to provide code for your custom service worker. For now, it will be very simple and will only contain the service worker skip waiting logic. This code will be appended for the actual service worker code.

It's not much code, but right now we can be sure that the new service worker will take over the old one.

How to “update” Service worker, i.e. check the availability of the latest version?

So far, it all looks quite straightforward, but we need the most important piece of the whole picture - we need to know when the changes to our web application occur. In order to do this, we need to force our service worker to “update”. The name for that operation may be confusing because it’s not update itself - rather, it’s checking whether the new version of the application is available. Let's take a look at this piece of code:

This will download the newest version of the service worker file from the server and compare it with the current version to detect any differences. It will fire an event that we can handle by 

 which was described previously. You may ask how the application “knows” that there were changes in code. When you take a look at the build directory, you can see a file like this.

If you see the content of this file, you will notice something like this:

When any file changes, then in precache file there will be different revision numbers and name of precaching file hash ( in the name ) changes. This file is included in the service worker file so if the name is changed, then the service worker file changes so the service worker can notice that change.

How to add a Progressive Web Application to the home screen in iOS?

The last thing we need to cover is determining when to check for the update. Of course, using the setTimeout() feature available in React allows to periodically check for updates of the new version. But this approach can cause some unexpected issues and unnecessary performance costs so we believe that it’s not enough.

We decided to take advantage of the PWA lifecycle and web API visibility change feature, so once users display the main screen of the application, we catch that event and force the service worker to update. Let's take a look at the following code:

Note: This approach may not work on Google Chrome. If you’re using Chrome, consider different events like scrolling or clicking a button.

We can catch the visibility change event which is fired when the application is displayed on the user’s screen. However, this event is fired when the app is shown and when it’s hidden so we need to check what the value of the hidden property is to determine if it’s displayed.

So now we have all the pieces fitting together and the final flow looks like this: The user opens PWA --> PWA catches the visibility change event and forces the service worker to update → the service worker checks if a new version of the application is available → we handle the update event by showing the refresh bar to the user → The user restarts the app (iOS) or refreshes it (Android) to get new content.

You can see that there are some differences between iOS and Android. To help you understand that better, let’s take a look at the following table.

As you can see, there are a lot of different pieces involved in the process of refreshing your PWA. But in the end, it will be very beneficial for your users. At Solidstudio Software House, we followed this approach in our product 

 to make sure that users have the latest version of the application. In our experience, Chrome seems to have a more stable and reliable environment when it comes to supporting PWA and we still need to fix some unexpected issues for iOS.

Learn how to overcome common Progressive Web Application challenges

Our UX process

29 MARCH 2022 • 8 MIN READ