Role: Product designer
Timeline: throughout 2017
Bigpipe is an internet service provider (ISP) and is, as they say, "Internet the way it should be". Simple, cheap and unlimited. It's a company that was part of the Spark Ventures program, like other promising start ups at the time (Skinny, Lightbox, Morepork...).
This startup vibe was reinforced by the fact that we were all working in the same space, and in an Agile environment, in the middle of a Spark tower, and all had a lot to prove. Very motivating times.
Throughout my journey working for Bigpipe, I had the chance to be the main product designer on their two primary programs of work: 1. the website's new features roadmap 2. Bigpipe app - a revolutionary app at the time, that would allow you to get more control over your internet.
I worked closely with the product owner, pitching design solutions, enhancing existing ones, and I was a shared resource for the two scrum teams responsible for digital deliveries (website and app).
My mission was to be efficient at delivering innovative and helpful for the end customer products and features. I was responsible for creating great quality designs and experiences that solve customer pain points.
The initial brief was as simple as that: create a remote for your internet.

The goal was to simplify customer's access to their internet - give them more control, stability and safety.
We have to keep in mind the context in which the idea came from and the time too. In 2016, the fibre offer was only available to a minority of people, meaning majority of customers only had access to a slower ADSL or VDSL connection. Buffering was a real issue, especially in a family or flat sharing situation where multiple people would use the connection simultaneously.
It all started with how all new products should start: by solving a problem or addressing a customer pain point.
The main identified pain point was, buffering, resulting in a number of customers experiencing bad internet. Additionally, there were  numerous recurring feedback regarding control, security and safety, which needed to be acknowledged.
With a fellow designer we organized a co-design session to try to work on finding solutions to these issues. We had participating to this session: main stakeholders, a couple of customers, designers, developers. The most interesting point was that every participant had different usage of Internet which helped broaden the spectrum of ideas explored.
How was the session organised?

First, the principal stakeholders briefed the audience about the intention of the new product and it was going to solve and who it was supposed to be designed for (Bigpipe personas are majoritarily leaning on the tech savvy side).
We then after a quick ice breaker asked the participants to sketch a story board representing how their idea could help to solve the problem.

Now, a good thing to keep in mind is: in workshops like these, it's not about thinking too long and trying to find the perfect solution. Timeframes are very shorts and it's about sharing about your own experiences, and how it could help in your context. Only after come
discussions, debates and collaboration, that allows participants to bounce off others ideas, refine theirs, and overall stimulate creative thinking and fast solution iterations.

Everyone presented their ideas, we stuck all those story boards to the wall as a reference for help and inspiration.
Having all the different contexts of usage in mind (and on the wall), we asked the participants for the next exercise to sketch what the product itself could look like. The only constraint here was to restrict it to a mobile experience (a remote is usually pretty portable).
After this fast and more interface focused exercise, everyone presented back to the audience their solutions and why they made their choices.
People then got to comment on each other idea using post its in the form of "I like' and "I wish". This allows to raise positive points as well as concerns in a constructive way. Based on those feedback, participants got to spend a little more time to refine their solution before an
ultimate round of presentation.
In the last exercise, we summarized the most relevant pitched features used in participant sketches onto post its and sorted them by priority for each user profiles.

We ended the session with a good idea of the features that needed to be built and some good interface concepts to explore and mix to get the best out them.
After some research work was done by network experts and developers on what was actually doable technically, I started the work to bring all the innovative features we talked about for so long into something that could exist (and will, after some development work).
The choice was made to build native applications for both iOS and Android as we had the expertise and resources in house. That's something important I had to keep in mind during the interface design process, to provide the best experience for both user channels. I would need to respect each platform guidelines and standards in order to keep the navigation consistent and familiar for the end user.
The process of creating the user interface was pretty simple, as the MVP version of the product would have to be simple. No big research on information architecture for example. I started with defining the main user flows, sketched rough paper wireframes, got some
validation from stakeholders, then moved to digital wireframing with more focus on usability, to finish with the last iteration where I added the visual design layer, following branding guidelines.
A scrum team was dedicated to this project and while the UI and testing were being done, the foundation work began.

That's just after that a close collaboration with the team really emerged. I was really embedded in the team. What made the communication very easy and efficient, other than the
fact that we were all sitting together, is that I participated in all the scrum rituals. It really helped, not only make the hand over a breeze but also learn and improve over time as we would refine our ways of working (retrospective meetings had a crucial role to determine how to best work together).
After months of focusing on building the MVP, the app finally saw the light of day! As the team worked on delivering the MVP I spent time refining and building new features, a product development never ends...
The hardest thing during this process was probably to try and find the clearest way to present the information to the user and making sure it was easily understood. To make sure it was the case we planned user testing sessions with some Bigpipe customers. This way we would find out if anything was wrong in terms of usability and to have a feel about the interest in the future product.
The interviews planned were 40-45 min long, testing the product with 8 customers. Each individual would be asked prior to start if they were Android or iOS users. We then could start the interview by handling them the corresponding device (two prototypes were built one for iOS, one for Android).  The two main objectives of these user testing sessions were to test
usability and clarity of the service, and to get a sense of whether or not that product could help them in their day to day lives.

We got really positive feedback from these sessions and a high System Usability Scale (SUS) score, which was very encouraging.
I learned so much during my time at Bigpipe and notably working on the Bigpipe app.

It's not often that you get the opportunity to be part of a product life development process in its entirety. From the workshop to get some ideas and concepts to the product launch, it was amazing to be in charge of the design of such an innovative product.
From a personal perspective, it truly helped me develop my full stack designer skills.

But I also learned a lot about working in an Agile environment, all the rituals and their importance. Sometimes your way of working is different from someone else's and acknowledging that is important. Find a middle ground, or stick to what will make the team work in best conditions.
I will always remember that experience as a wonderful human and professional adventure.
In a different session with the product owner, we refined this prioritization board to make it a clearer list that will drive our roadmap.
This case study showcase the design flows used at Bigpipe for product design
A product designer way of doing
Bigpipe
Context
Mission and responsibilities
Case study: from an idea to a live product
Challenge
Way of working
Learnings
How to go from a succinct brief to a live product?
From paper to reality
Time to make it real
Whiteboard after a co-design workshop
The first feature prioritization list
User flows and wireframe sketches
Illustration of the Agile methodology used (SCRUM framework)
Back to top
Image
Case studies
A product designer way of doing
ImageImageImageImageImageImageImage
Role: Product designer
Timeline: throughout 2017
Bigpipe is an internet service provider (ISP) and is, as they say, "Internet the way it should be". Simple, cheap and unlimited. It's a company that was part of the Spark Ventures program, like other promising start ups at the time (Skinny, Lightbox, Morepork...).
This startup vibe was reinforced by the fact that we were all working in the same space, and in an Agile environment, in the middle of a Spark tower, and all had a lot to prove. Very motivating times.
Throughout my journey working for Bigpipe, I had the chance to be the main product designer on their two primary programs of work: 1. the website's new features roadmap 2. Bigpipe app - a revolutionary app at the time, that would allow you to get more control over your internet.
I worked closely with the product owner, pitching design solutions, enhancing existing ones, and I was a shared resource for the two scrum teams responsible for digital deliveries (website and app).
My mission was to be efficient at delivering innovative and helpful for the end customer products and features. I was responsible for creating great quality designs and experiences that solve customer pain points.
The initial brief was as simple as that: create a remote for your internet.

The goal was to simplify customer's access to their internet - give them more control, stability and safety.
We have to keep in mind the context in which the idea came from and the time too. In 2016, the fibre offer was only available to a minority of people, meaning majority of customers only had access to a slower ADSL or VDSL connection. Buffering was a real issue, especially in a family or flat sharing situation where multiple people would use the connection simultaneously.
It all started with how all new products should start: by solving a problem or addressing a customer pain point.
The main identified pain point was, buffering, resulting in a number of customers experiencing bad internet. Additionally, there were  numerous recurring feedback regarding control, security and safety, which needed to be acknowledged.
With a fellow designer we organized a co-design session to try to work on finding solutions to these issues. We had participating to this session: main stakeholders, a couple of customers, designers, developers. The most interesting point was that every participant had different usage of Internet which helped broaden the spectrum of ideas explored.
How was the session organised?

First, the principal stakeholders briefed the audience about the intention of the new product and it was going to solve and who it was supposed to be designed for (Bigpipe personas are majoritarily leaning on the tech savvy side).
We then after a quick ice breaker asked the participants to sketch a story board representing how their idea could help to solve the problem.

Now, a good thing to keep in mind is: in workshops like these, it's not about thinking too long and trying to find the perfect solution. Timeframes are very shorts and it's about sharing about your own experiences, and how it could help in your context. Only after come
discussions, debates and collaboration, that allows participants to bounce off others ideas, refine theirs, and overall stimulate creative thinking and fast solution iterations.

Everyone presented their ideas, we stuck all those story boards to the wall as a reference for help and inspiration.
Having all the different contexts of usage in mind (and on the wall), we asked the participants for the next exercise to sketch what the product itself could look like. The only constraint here was to restrict it to a mobile experience (a remote is usually pretty portable).
After this fast and more interface focused exercise, everyone presented back to the audience their solutions and why they made their choices.
People then got to comment on each other idea using post its in the form of "I like' and "I wish". This allows to raise positive points as well as concerns in a constructive way. Based on those feedback, participants got to spend a little more time to refine their solution before an  ultimate round of presentation.
In the last exercise, we summarized the most relevant pitched features used in participant sketches onto post its and sorted them by priority for each user profiles.

We ended the session with a good idea of the features that needed to be built and some good interface concepts to explore and mix to get the best out them.
After some research work was done by network experts and developers on what was actually doable technically, I started the work to bring all the innovative features we talked about for so long into something that could exist (and will, after some development work).
The choice was made to build native applications for both iOS and Android as we had the expertise and resources in house. That's something important I had to keep in mind during the interface design process, to provide the best experience for both user channels. I would need to respect each platform guidelines and standards in order to keep the navigation consistent and familiar for the end user.
The process of creating the user interface was pretty simple, as the MVP version of the product would have to be simple. No big research on information architecture for example. I started with defining the main user flows, sketched rough paper wireframes, got some
validation from stakeholders, then moved to digital wireframing with more focus on usability, to finish with the last iteration where I added the visual design layer, following branding guidelines.
A scrum team was dedicated to this project and while the UI and testing were being done, the foundation work began.

That's just after that a close collaboration with the team really emerged. I was really embedded in the team. What made the communication very easy and efficient, other than the
fact that we were all sitting together, is that I participated in all the scrum rituals. It really helped, not only make the hand over a breeze but also learn and improve over time as we would refine our ways of working (retrospective meetings had a crucial role to determine how to best work together).
After months of focusing on building the MVP, the app finally saw the light of day! As the team worked on delivering the MVP I spent time refining and building new features, a product development never ends...
The hardest thing during this process was probably to try and find the clearest way to present the information to the user and making sure it was easily understood. To make sure it was the case we planned user testing sessions with some Bigpipe customers. This way we would find out if anything was wrong in terms of usability and to have a feel about the interest in the future product.
The interviews planned were 40-45 min long, testing the product with 8 customers. Each individual would be asked prior to start if they were Android or iOS users. We then could start the interview by handling them the corresponding device (two prototypes were built one for iOS, one for Android).  The two main objectives of these user testing sessions were to test
usability and clarity of the service, and to get a sense of whether or not that product could help them in their day to day lives.

We got really positive feedback from these sessions and a high System Usability Scale (SUS) score, which was very encouraging.
I learned so much during my time at Bigpipe and notably working on the Bigpipe app.

It's not often that you get the opportunity to be part of a product life development process in its entirety. From the workshop to get some ideas and concepts to the product launch, it was amazing to be in charge of the design of such an innovative product.
From a personal perspective, it truly helped me develop my full stack designer skills.

But I also learned a lot about working in an Agile environment, all the rituals and their importance. Sometimes your way of working is different from someone else's and acknowledging that is important. Find a middle ground, or stick to what will make the team work in best conditions.
I will always remember that experience as a wonderful human and professional adventure.
In a different session with the product owner, we refined this prioritization board to make it a clearer list that will drive our roadmap.
This case study showcase the design flows used at Bigpipe for product design
A product designer way of doing
Bigpipe
Context
Mission and responsibilities
Case study: from an idea to a live product
Challenge
Way of working
Learnings
How to go from a succinct brief to a live product?
From paper to reality
Time to make it real
Whiteboard after a co-design workshop
The first feature prioritization list
User flows and wireframe sketches
Illustration of the Agile methodology used (SCRUM framework)
Back to top
Image
Case studies
A product designer way of doing
ImageImageImageImageImageImageImage
A product designer way of doing
Case studies
A product designer way of doing
ImageImage
Bigpipe
Role: Product designer
Timeline: throughout 2017
Bigpipe is an internet service provider (ISP) and is, as they say, "Internet the way it should be". Simple, cheap and unlimited. It's a company that was part of the Spark Ventures program, like other promising start ups at the time (Skinny, Lightbox, Morepork...).
This startup vibe was reinforced by the fact that we were all working in the same space, and in an Agile environment, in the middle of a Spark tower, and all had a lot to prove. Very motivating times.
Throughout my journey working for Bigpipe, I had the chance to be the main product designer on their two primary programs of work: 1. the website's new features roadmap 2. Bigpipe app - a revolutionary app at the time, that would allow you to get more control over your internet.
I worked closely with the product owner, pitching design solutions, enhancing existing ones, and I was a shared resource for the two scrum teams responsible for digital deliveries (website and app).
My mission was to be efficient at delivering innovative and helpful for the end customer products and features. I was responsible for creating great quality designs and experiences that solve customer pain points.
It all started with how all new products should start: by solving a problem or addressing a customer pain point.
The main identified pain point was, buffering, resulting in a number of customers experiencing bad internet. Additionally, there were  numerous recurring feedback regarding control, security and safety, which needed to be acknowledged.
After some research work was done by network experts and developers on what was actually doable technically, I started the work to bring all the innovative features we talked about for so long into something that could exist (and will, after some development work).
The choice was made to build native applications for both iOS and Android as we had the expertise and resources in house. That's something important I had to keep in mind during the interface design process, to provide the best experience for both user channels. I would need to respect each platform guidelines and standards in order to keep the navigation consistent and familiar for the end user.
The process of creating the user interface was pretty simple, as the MVP version of the product would have to be simple. No big research on information architecture for example. I started with defining the main user flows, sketched rough paper wireframes, got some
validation from stakeholders, then moved to digital wireframing with more focus on usability, to finish with the last iteration where I added the visual design layer, following branding guidelines.
The interviews planned were 40-45 min long, testing the product with 8 customers. Each individual would be asked prior to start if they were Android or iOS users. We then could start the interview by handling them the corresponding device (two prototypes were built one for iOS, one for Android).  The two main objectives of these user
testing sessions were to test usability and clarity of the service, and to get a sense of whether or not that product could help them in their day to day lives.

We got really positive feedback from these sessions and a high System Usability Scale (SUS) score, which was very encouraging.
A scrum team was dedicated to this project and while the UI and testing were being done, the foundation work began.

That's just after that a close collaboration with the team really emerged. I was really embedded in the team. What made the communication very easy and efficient, other than the
fact that we were all sitting together, is that I participated in all the scrum rituals. It really helped, not only make the hand over a breeze but also learn and improve over time as we would refine our ways of working (retrospective meetings had a crucial role to determine how to best work together).
After months of focusing on building the MVP, the app finally saw the light of day! As the team worked on delivering the MVP I spent time refining and building new features, a product development never ends...
I learned so much during my time at Bigpipe and notably working on the Bigpipe app.

It's not often that you get the opportunity to be part of a product life development process in its entirety. From the workshop to get some ideas and concepts to the product launch, it was amazing to be in charge of the design of such an innovative product.
From a personal perspective, it truly helped me develop my full stack designer skills.

But I also learned a lot about working in an Agile environment, all the rituals and their importance. Sometimes your way of working is different from someone else's and acknowledging that is important. Find a middle ground, or stick to what will make the team work in best conditions.
I will always remember that experience as a wonderful human and professional adventure.
The hardest thing during this process was probably to try and find the clearest way to present the information to the user and making sure it was easily understood. To make sure it was the case we planned user testing sessions with some Bigpipe customers. This way we would find out if anything was wrong in terms of usability and to have a feel about the interest in the future product.
With a fellow designer we organized a co-design session to try to work on finding solutions to these issues. We had participating to this session: main stakeholders, a couple of customers, designers, developers. The most interesting point was that every participant had different usage of Internet which helped broaden the spectrum of ideas explored.
How was the session organised?

First, the principal stakeholders briefed the audience about the intention of the new product and it was going to solve and who it was supposed to be designed for (Bigpipe personas are majoritarily leaning on the tech savvy side).
We then after a quick ice breaker asked the participants to sketch a story board representing how their idea could help to solve the problem.

Now, a good thing to keep in mind is: in workshops like these, it's not about thinking too long and trying to find the perfect solution. Timeframes are very shorts and it's about sharing about your own experiences, and how it could help in your context. Only after come
discussions, debates and collaboration, that allows participants to bounce off others ideas, refine theirs, and overall stimulate creative thinking and fast solution iterations.

Everyone presented their ideas, we stuck all those story boards to the wall as a reference for help and inspiration.
Having all the different contexts of usage in mind (and on the wall), we asked the participants for the next exercise to sketch what the product itself could look like. The only constraint here was to restrict it to a mobile experience (a remote is usually pretty portable).
After this fast and more interface focused exercise, everyone presented back to the audience their solutions and why they made their choices.
People then got to comment on each other idea using post its in the form of "I like' and "I wish". This allows to raise positive points as well as concerns in a constructive way. Based on those feedback, participants got to spend a little more time to refine their solution before an ultimate round of presentation.
In the last exercise, we summarized the most relevant pitched features used in participant sketches onto post its and sorted them by priority for each user profiles.

We ended the session with a good idea of the features that needed to be built and some good interface concepts to explore and mix to get the best out them.
In a different session with the product owner, we refined this prioritization board to make it a clearer list that will drive our roadmap.
Context
Mission and responsibilities
Challenge
Way of working
Learnings
Case study: from an idea to a live product
This case study showcase the design flows used at Bigpipe for product design
The initial brief was as simple as that: create a remote for your internet.

The goal was to simplify customer's access to their internet - give them more control, stability and safety.
We have to keep in mind the context in which the idea came from and the time too. In 2016, the fibre offer was only available to a minority of people, meaning majority of customers only had access to a slower ADSL or VDSL connection. Buffering was a real issue, especially in a family or flat sharing situation where multiple people would use the connection simultaneously.
How to go from a succinct brief to a live product?
From paper to reality
Time to make it real
Back to top
Image
Whiteboard after a co-design workshop
Image
The first feature prioritization list
ImageImageImage
User flows and wireframe sketches
Image
Illustration of the Agile methodology used (SCRUM framework)