Designing with an unexpected turn: From IPTS to Shuddle
The IPTS (Interplanetary Travel Syndicate) is a fictional transportation network created as part of the Dribbble Scaling Design Systems course. This fictional company gives people the service of transportation from world to world within our galaxy.
As part of the brief, it was requested to launch 3 unique offerings, from which my job was to create all three websites. These websites consisted in:
ipts.org, an informational website where you can find the latest news and happenings with the IPTS and related topics.
IPTS Travel, a website where you can browse and book travel to and from multiple destinations within our galaxy.
IPTS Rail, a real-time updated web app where you can view lines, routes, and times for all the different commuter lines.
An unexpected turn 🚨: halfway through the two-week project, we were informed that IPTS would be renamed "Shuddle". This came as a complete surprise to us, however it was a great exercise to test the knowledge acquired during the course and quickly readapt the designs to the new branding.
In this case study I will show the process that I followed until the final result and even the future steps that this work could follow.
My role
As Senior Product Designer my job was to help IPTS to shape the future of their offerings. To be able to deliver the project in 2 weeks I had to look at the products holistically, and see how I could take advantage of the UI created to be applied across products.
I started the project by myself first, but got help from my "secret" team (that I will reveal at the end) that allowed me to speed up the process. Also later in the middle of the first week, joined a developer colleague who also was doing the course to work together in this project.
The scope
This project only considered the main pages/screens of the different offerings of the company, therefore the designs were built considering these 3 main screens only.
As a note, in a real scenario, strategically, this project may have required the collaboration of at least 3 product designers (for each offering). The designers may have aligned to define the experience for each site. But practically for this 2-week project, this exercise was good enough as a starting point where the creation and documentation of the process contributed to shape a cohesive and consistent design.
Goals
The goal was to deliver a design that’s both intuitive, consistent and efficient. I would do this by creating, leveraging and documenting their future design system, while I design the different sections of their websites. So the final deliverables would consist in:
3 products/offerings
a design system
a documentation site
However, as mentioned above, once the first part of the project was in the process to be delivered, the company launched a rebranding, from which I would have to update the designs. The creation of a design system came handy, to make the updates and propagate it to the designed products. More detail will come below.
Process
Phase one: Discover
As IPTS’ value proposition is not something common or known in the present 2023, I needed first to look for inspiration in other existent services to bring up a few set of ideas that helped me to get started.
This discovery considered similar existent websites and services, to understand how they are structured and what features would be required for IPTS.
I met my team to get some ideas to start defining a ground for all the required content. I brainstormed which features could be necessary to have in each of these websites and what UI components could work in each other. The interactions took several iterations and reviews.
This was a very solid ground to start an analysis that could bring more clarity for all all the required content and features.
Phase two: Decode
I divided this first research and analysis in 3 categories, to match the different offerings of IPTS. I grouped a few samples as “News”, “Travel” & “Tracking”. This allowed to identify the UI patterns used in these different product typologies and start identifying commonalities.
I identified what UI elements repeated across the different websites categories, and listed a few component requirements according to general functionality and content. This provided a first layer to structure the content, and see opportunities to create UI elements that could work across the different IPTS websites.
I also analysed all the information gathered previously by the brainstorming sessions, and classified it to compare it with conclusions I got from the UI analysis.
The convergence from both sources of information helped me to have a wider scope to consider and start generating UI and content.
Phase three: Define
In this phase translated the previous insights into product requirements. From the previous research, I put together some UI samples and listed the minimum attributes that each of them could need. For example, for the header, it should have a logo, links, sign in and a button.
This part of the process was iterative and I repeated it for each UI component through the process, while still was trying to build the big picture. For example, I grouped the 3 different websites offerings and tried to see in simple mockups how these elements would play in each of them.
This helped me to simplify the design process later, although I often had to make adjustments to make things fit.
This part of the process was iterative and I repeated it for each UI component, while still was trying to build the big picture. For example, I grouped the 3 different websites offerings and tried to see in simple mockups how these elements would play in each of them.
This helped me to simplify the design tasks later, although I often had to make adjustments to make everything fit.
This exercise gave me a summary of the minimum UI components I would need to build the 3 websites.
Phase four: Design
Before to define the foundations of the design in a system, I created the header as a component, to have something tangible where I could test colours and styles.
Using the coolors tool, I quickly tried a few colour combinations and tested in the header. I picked colours and a font that evoked the space concept and technology. After testing a few options, the next step would be to define those styles and document them in a Design System.
At the start, I didn’t know which colour could be used as accent, but I realised that having 3 (purple, turquoise & yellow) could be used to represent a different offering of IPTS.
Phase five: Document
Reaching this point in time, in order to keep things in order, I created a documentation site using Zeroheight, a really good resource to document the designs and have one single source of truth for the Design System. This way, before I build up the rest of components, I documented the colours and fonts, in the documentation site.
So Define-Design-Document was iterative, and it would be repeated for all the components required to design the 3 websites for IPTS.
Define > Design > Document
From this point, I also decided to explore supporting other devices, so when I created the UI components they could also adapt as well to tablet and phone.
This way, I considered the different breakpoints for each component depending on the device size.
I created a centralised canvas where as a pilot of the designs. The process to define the screens and design components came from top to bottom, starting from the header and so on.
Phase six: Develop
This process was collaborative, so while I was designing the components in Figma, I communicated the progress to my dev colleague, so I could get feedback and make some adjustments if it was necessary.
He provided inputs in the designs to reach results that made more sense, and also could be easier to implement. The idea was trying to optimise design and implementation for some components.
For example, for the footer, to make things simpler, my colleague suggested to check some components in Tailwind that we could use. I searched for one we could use and shared with him, so he got the code of it quickly. Then, I built it in Figma to add it to the Design System.
So while my colleague was creating the components in code, I was putting together the UI for the different websites and content for each of them.
This is how I reached the final result. Seeing the designs in the different offering contexts and device formats helped to speed up the process while being consistent.
The unexpected new request
As mentioned earlier, during the course of this exercise, while I still was building the components for the IPTS brand, I heard that a new branding was coming: Shuddle.
At that point in time, I didn’t know yet how I would organise both the Figma file and the Zeroheight documentation site. I highlight this, because although in a realistic scenario, a company like IPTS would have the budget to have both a Figma and Zeroheight licenses (with most of their features) this was not the case here.
Zeroheight only allows to link one Figma file with the free license. Therefore, I had to find a way to organise the new components in the same file. In the ideal scenario, I had created a copy of the current IPTS system, and start creating the new branded components in a separated file.
So, for what would come next, I structured the information keeping both brands, old and new in the same Figma file, and documented it in the Zeroheight.
Also, given the short time frame we had to implement the rebranding, I decided to stick with the same layout and apply the new styles to the components previously designed. In most of the cases the transition was a breeze, but in others I had to do more work than I expected.
New iteration
Phase one - Discover
With the arrival of the new branding, we had to rethink the design style of our UI. The requirement was to make a new modern UI that displayed the technology and modernity of the new Shuddle brand.
Initially I started to investigate for futuristic UI trends that could bring a fresh, modern and immersive experience. From these, it really called our attention Glassmorphism, where design elements, as its name conveys, features glass-like effects. All elements in this design style have a translucent/transparent look.
When these elements are placed on colorful backgrounds, the glass effect is accentuated. This also seemed a great new challenge, as we never had tried to reproduce such bold design style.
Looked for inspiration in Glassmorphism style to learn how it’s applied, and understand its features and principles.
Currently some drivers of this design style are Apple with its Vision Pro, Meta with its Quest 3 and Microsoft with its Fluent DS. This brought good inspiration to start exploring the possibility of applying this style in the rebranding of ITPS.
Design tokens
I mentioned earlier, I didn’t have the full license of Figma to try things as I was thinking I would fit them. However this limitation was useful, as the way I was organising the tokens for IPTS wasn't the most productive.
I was creating columns (themes) using variable tokens for each IPTS site, just changing the accent colour, and my plan for Shuddle was to create other 3 new columns for the different offerings.
Note: as a reminder, I was doing all this in the same Figma file to be able to link it with Zeroheight, due to the limitation of linking only one Figma file in the free license.
Phase two - Decode
Next step was to learn how to create this glass effects using Figma. This discovery process help me to understand how gradients are applied, as well as blur effects and shades.
I quickly put into test the glass styles and I refined it while I was getting closer to the best results. This helped to visualise the look and feel before starting to incorporate the styles to the system.
Phase three - Define
Having a basis to start practicing a few Grassmorphism iterations, I defined the colour system for the new Shuddle UI Kit. The new branding came with a new blue colour that replaced the previous one, and a new colour that I named as "Global" for the main logo.
When I created the styles for IPTS brand, I added to the system the essential. This brought later some issues, as I was too limited in colour options. When that happened I had to incorporate the missing colour to the system, for example with the grey shades. This time instead, I created different levels of shades that eased later the creation of design tokens. Also at this point, I created some gradients that could be applied for the glass materials.
I went back and forth trying to reproduce the Glassmorphism effect, and when it worked, I incorporated the gradient to the library as a colour style.
After several iterations I created my library of shades to start applying them in my new branded components. This was specially useful for my dev colleague who found value in understanding the process and stages I was following to apply gradients, transparency, effects and shades to achieve the glass look and feel in code.
Design tokens
I mentioned earlier, I didn’t have the full license of Figma to try things as I was thinking I would fit them. However this limitation was useful, as the way I was organising the tokens for IPTS wasn't the most productive.
I was creating columns (themes) using variable tokens for each IPTS site, just changing the accent colour, and my plan for Shuddle was to create other 3 new columns for the different offerings (see picture below)
Note: as a reminder, I was doing all this in the same Figma file to be able to link it with Zeroheight, due to the limitation of linking only one Figma file in the free license.
Figma in the student license only allows to create 4 themes. Although at the start I thought I would have to delete the IPTS themes, later I realised that I could approach this differently, and that I wasn't organising it in the best possible way.
So, I made it fit in a way that it worked with 2 themes only, one for the previous brand, IPTS, and other for Shuddle. I just created 1 column for each brand, giving a placeholder to each brand's accent colours. This way, it really simplified things and made it easier to manage.
Phase four - Design
Now started the fun part of starting to apply these styles to the most basic components and making adjustments in the library when it was necessary.
In the way I had organised my tokens by themes with IPTS (as showed above), initially helped me to simplify the creation of components. The accent colour was the token applied for colour, so when the frame had the corresponding brand token, the colour was switching to it. That explains why I only had 1 set of buttons for the IPTS component.
Now when I created the new set of buttons for Shuddle, I had also to create variations for styles.
As the new themes are divided in the old IPTS, and Shuddle, I had to create the accent brand colour variations for each component.
I kept the same structure for old and new components, so updating the styles of the new components was almost a breeze in most of the cases. In the process I also made adjustments in a few values to increase the contrast and to improve readability.
But, it was not all roses. Not all my components matched 1-1 with what I previously had defined in IPTS. The hero section is the one I would have to change the most, since when I tested the new styles, I realised that it was totally off with the rest of the UI.
Glassmorph style is represented mostly on floating groups/windows, in a quite simple way. In the hero section instead, the picture was fixed independently, provoking a visual shock. I also realised that is not enough with knowing to represent the glass style, but the harder part is how to find balance in applying it and not overuse it. In the examples above, the card sections and cards components didn’t look really good as the glass material was overused (this is what I meant previously about "education for perception").
For this reason, sometimes I had to give a step back and take a new approach. This time, I made a new hero component that integrated the header, to give it the aspect that features Glassphorphism style.
Applying the styles and removing the picture made an impressive change in the design. It also improved the overall look and feel of the UI, and matched the style in the design.
Having defined a good foundation building the "atoms", "molecules" and "organisms" really simplified the process of transitioning to the new brand. It helped me to adapt the designs quickly when it was required.
In the video below, the component "Advanced search" was part of the new hero section, so when it was time to create the new variations, the process of creating them was really fast.
One another important step was simplifying how the style was applied in the UI, so I tried to reduce the application of the glass style to the card components, giving a simpler and more relaxed look and feel.
This is how, almost without realising, I created a full Design System to support the designs created, first for IPTS, and later transitioning to Shuddle. I named this Design System as "Far Away".
Phase five - Document
Although for IPTS documentation came more natural and iterative, for Shuddle it had to wait a bit more. The reason was that I needed a lot of testing and experimentation with the styles before to start documenting. It was a better use of my time, to create the content of the different Shuddle sites first, testing the UI with everything in context, making adjustments to the components that required it, and then documenting.
In this process I also kept my dev colleague informed of the changes in the designs and the system. So when the designs were finalised, he could also make his own research to be able to apply the Glassmorphism styles to the components designed.
Documenting the styles and components as well as creating the content for the different pages was quite time consuming. Luckily, Zeroheight allows you to sync the site with you published components in Figma. It speeds up the process a lot, and updating design changes comes from a mouse's click when everything is done right.
I spent more time renaming components added to the site, creating sections for those components and changing background colours than bringing components to Zeroheight. There are some UX improvements that could come handy in productivity, but overall it's a great tool with many resources to get started quickly.
I also enjoyed understanding the process of documenting new releases in a changelog. I put into practice how to communicate new system versions and components during the process.
After all the work done, there is still a lot of documentation work that could be added to our documentation site for the Far Away Design System.
Design Systems are live products, with constant upgrades and improvements. In the current state of development of the app, some components still would require to be used and tested in more pages, to capture patterns of usage that helped to define more specific rules of application.
For the scope of this project, the request was designing the main page of the 3 sites, only. To build a more mature documentation site, it would come from the development of the rest of possible flows and interactions for each of these sites.
Phase six - Develop
In parallel while I worked in Figma, my colleague investigated how to apply the styles in the designs. We had 1-1 meetings where I communicated the progress of the designs and the logic behind it. He supported the ideas and we made the necessary adjustments/agreements to see the design implemented.
My dev colleague planned to develop the different components applying the new styles. He first would follow a similar process than me, trying to create components in code for testing and learning. Once he achieved the right results with his experimentations, he would code and document the component to be used later to build the pages.
Future steps
The Glassmorphism style can give much more than just simply placing the UI in the traditional way we know (flat and scrollable). For this project, the rebranding was a total surprise, and the glass style was an extra challenge we decided to take.
However for the timeframe of 2 weeks, we wanted to deliver at least an MVP of the product.
Future steps for the design
In examples of UX like Vision Pro or Quest 3, the way of interacting with the UI is more spacial and immersive. To reach such result we would require extra time for investigation and experimentation.
I envisioned a sort of experience that wasn't like the traditional way of navigating applications, but it was something that could dynamically change depending where you go within the interface.
However, I still tried to go a little bit further and tried some quick prototypes of how this UI could work in a more dynamic way. Click here to see the prototype.
Both from the design and development side, this project was a challenge with so many learnings, and we hope to continue doing some discovery to reach a Shuddle 2.0. As some tech trends predict, the future of UX may be more spacial than in a single flat screen.
Future steps for the documentation site
While creating more pages and increasing the usage of components, new rules would need to be defined. I have not doubt that at this point there are still lots of things that could be done better, and they would need to be updated and documented. That would mean to add more detail in the usage of the components, specify do's and dont's, adding code and any other details that helped to ease the design of pages and UI for the brand's products.
Future steps for development
To be able to implement the defined styles and explore other more dynamic interactions for the UI displayed in screen, if it required movement, change of backgrounds, or layered position in the space.
Conclusion
Doing this project was a great and intensive experience, which really tested my skills. Earlier at the start of this project, I mentioned I would have the help of my "secret" team. Well, if you guessed it right, that team was AI. We are in such an interesting era of technology that is enabling us to produce faster, without the need always to have to depend on others.
Great part of the initial phases of the project I needed ideas, lots of them. At that time, I used my secret team to keep things running. A combination of brainstorming content, features and ideas of design components that could be used across the applications offered some complementary clarity to the amount of information I was trying to synthesise. AI was like having a team to delegate tasks that quickly came back to me to generate new ideas or possible solutions.
I contrasted those ideas with my own analysis and repeated many times until the information gathered made more sense, since as we know, AI also can be very inaccurate.
This project was a great opportunity to improve my skills, both in design, Figma usage, exploration of new styles, definition of tokens, design systems creation, collaboration, understanding how components work in code, chronicling and documenting. A big bomb of information that came like steroids in design knowledge and skills, that now I'm applying with my team in my current company to improve our product.
