Menu
eBikes play an important role in the area of future mobility. So it’s very important to get the basics right, therefore we worked on one of the most critical parts: meaningful features for the safety and security of both bike and rider.
In my team, we took care of the locking and unlocking of an eBike. It was a specific digital feature. Communication between hardware and software was essential for this project.
📣
📖
⚠️ Since this project is constantly evolving and therefore some parts still under NDA, I can only show some of the details ⚠️
In the very beginning we defined the user value of our idea. The feature makes it unattractive for thieves to steal a bike because single components can not be used anymore.
After defining the value, we went straight into exploring the single use cases. We worked with our personas (which the greater design team developed) and the technical possibilities (which we defined together with the hardware team) to develop the basics for the feature.
To understand the pain points and how our users feel, we need to understand their process and flow. Therefore we were creating an as-is scenario to go through their journey, step by step.
To know where we can go and where we can’t go with our concepts, we needed to check for limitations and restrictions (technical or anything else). So we discussed all the topics we needed to have in the back of our heads with the hardware team, the backend-developers, and other stakeholders.
A few requirements needed to be met to successfully solve the problems our users are facing. Therefore we described the user’s pain points via these Needs Statements. We grouped them in 3 different parts we needed to cover: Enabling/Disabling Lock, Lock Settings, and Lock Status.
A user flow helps to generally understand the path the user is going through to achieve their goals. In the best case, it involves all basic use cases plus edge cases. We developed this user flow to get a good understanding and basic architecture for the wireframes.
After we defined the most important parts (persona, use cases, restrictions) and went through the user flow, we had a big session to brainstorm ideas and flows that solve the user’s problems.
After we’ve developed these initial wireframes, we created different prototypes to get first feedback through user tests. For the very first tests we gathered stakeholders and users from inside the company who never have touched or even heard of the feature to get an untainted view. In order to get feedback on specific parts of the feature, we created various tasks for the users to complete with an additional set of questions about the functionality.
We gathered all the pain points the users where experiencing while testing the new feature and clustered them to get a good overview.
The problem areas and user feedback from the user tests helped us shape the tasks for the next iteration of the concept. We defined the to-dos and prioritized them to get the feature done in the given time frame.
… to create the best experiences for our users with the constraints we had. There were dozens of hardware dependencies (e.g. Bluetooth, battery life, other bike components). But also dependencies to other teams that had to be respected without neglecting the needs of the users.
Lots of issues that you don’t think about in the very beginning and that make concepting really difficult, so it was really important to understand BLE in detail and develop the designs accordingly.
Thanks to the well-timed sprint reviews, retros, and planning, we picked up a lot of speed. But it took a long time to establish the pattern within the team, which made it all the better.
Communication with the hardware guys wasn’t always easy. It was important to talk to them early and often enough in order to not have to discard great ideas because they couldn’t be working.
