Welcome to the Figma series brought to you by Design at Scale™ — Academy(↘︎Link). This article will focus on the product design settings for teams of one, ten, and one hundred — teams that build digital products(↘︎Link), applications(↘︎Link), SaaS solutions(↘︎Link), and so on.
Different to; retail websites, campaign pages, and lead generation funnels. We are talking about environments where product function superseded creativity.
Designing the product has a few specific processes that reflect how the design files are set up, handled, branched, and archived. Therefore, each stage's story and modularised completeness need to be fulfilled, and the certified product owner needs to sign off on it.
– Proposition Shaping
– Design Shapin
– Refinement (not mandatory for smaller teams)
– Development
– Show and Tell (not mandatory for smaller teams)
–Release / Integration
Proposition Shaping
This stage of the project is very much about the business. However, recently, we have experienced more involvement in design, and therefore, designers are around the round table making executive decisions.
FigmaJam (↘︎Link) plays a vital role in laying down the initial foundation for the concept (↘︎Link) and prototyping the basic user journey, including the data model(↘︎Link), so that all parties are on the same page regarding MVP (↘︎Link).
The output of this first session is so-called Schemas—whiteboard wireframes (↘︎Link) that allow all parties to have a slightly greater understanding of the proposition's direction and physical shape.
Business and Development functions are going through similar exercises. If the organisational unit decides to collect all data in one space, allowing all parties to share the findings, it ultimately strengthens the proposition and builds a more connected team.
Reach out for more PropositionShaping Templates at Design at Scale™ – Supply or directly on our dedicated space in Figma.
Design shaping
The proposition is shaped – that means you and your team know what you are building. The following stage ensures that all your findings from competitive landscape analysis, the user behaviours, navigation and mental model, and content strategy build your data model. After collecting our inspirations regarding specific functions or the entity, we’ll design the very first version of our proposition. It’s important to mention that a basic Mobile app sometimes needs only one single Figma file. In the case of designing the financial ecosystem for the FX trading platform, we might end up with 150 Figma files connected. The only difference is the naming convention (↘︎Link); therefore, these structures remain – they only grow exponentially.
The output of this stage is the fully designed E2E(↘︎Link) flow for specific features or, in small projects, the entirety of the product. It is essential to mention this. If you are in a team that is designing a mobile app for treasure hunt recording GEO location, you do not need such a comprehensive setting or process. As the complexity grows, you might consider having a bit of rigour to control not only the designs but also the way they are communicated across the internal (external) teams(↘︎Link).
In a bigger proposition with 50+ screens, you’ll probably deliver feature after feature and repeat this process until you reach the Candidate Release (↘︎Link) of your first product.
While customer experience designers discussed the journey scenarios and the validity of the proposition with the business analyst, our UI design team explored the visual representation and the correct visual hierarchy on the page. CX outputs are an Experience Map(↘︎Link) and multiple User Journeys(↘︎Link), where UI outputs are UI design and prototypes linked back to Jira and described in Confluence (↘︎Link) completing this stage and moving on to another.
Refinement (not mandatory)
This stage is recommended for teams with 50+ people refining and creating all error scenarios, notification, overlays etc. so that we can reduce the code refactoring(↘︎Link). In the past this stage was more about prototyping and assets management than anything else.
It also meant greater – and closer – collaboration with our development colleagues. First, we sign the basics functionality, allowing our dev team to start building, and second, we start refining the features details FRs(↘︎Link) and NFRs(↘︎Link). Which overall leads to sequential improvement of one specific feature. No one has waited for anyone, and we have progressed in the same direction with small yet consistent increments – improving the product as we go.
Figma and its versioning allowed us to make progressive improvements and as agreed and signed off we merged the branches and moved the design to the Release_Name branch.
At this point, we have reached the first level of modularisation (↘︎Link), which allows us to have a discussion about the Design System and its first iteration. Please follow the link for more details (↘︎Link)
Development
This phase is more about supporting our development colleagues, thank design. More importantly, the code console in Figma delivers greater extension to our work, and capability is rising. We can rely on the correctness of our design documents driving the development. Show basic code that can be used in Swift(↘︎Link), HTML5(↘︎Link), or React(↘︎Link) to replicate the visual representation on the stage.
Once the dev team validates our prototypes, our UI colleagues have enough time to finalise the design knowledgebase before we get to the final sign-off and release. It’s pretty standard that at this stage, we start the versioning, and the cycle goes back to prototyping and, yet again, visualising to save time in Development and allow additional user testing before the release, reducing the cost.
Once the product is released, it goes through the testing Q&A(↘︎Link), allowing the rest of the team to record bugs that inform us of additional changes to the proposition or its function.
Finally, this entire creation process is documented and assigned to Jira tickets(↘︎Link), which represent the status in the current sprint and show when the specific part of the experience will be delivered. This informs the product owner and chief product officer when the feature will go live.
Show and tell (desirable – not mandatory)
Whether you are a sole designer or a design unit, you have to broadcast the change. Show and Tell is a weekly gathering that allows us to “Show and Tell” the story behind the proposition from a CX point of view while equally highlighting the benefits of mutual UI facelift or brand direction.
Undoubtedly, presenting to one developer or an entire unit of developers means broadcasting the change. These sessions are very beneficial to development as they can see what we are cooking in the design kitchen and vice versa, and what is possible from all these thoughts.
Once the cadence of the “Show and Tell”(↘︎Link) is established, it becomes a safe space to debate the design. It’s not a review but more “tell me how to improve the user story we are building together.” This is very popular with developers on my own teams. The fundamental impact is that S&Ta is a safe space to discuss ideas and a place to collaborate. Let’s not misunderstand this space for designing by committee.
This is the designer's playground, and nothing is mandatory/definitive.
Integration
Integration is the last part, and the design files re-play the role of knowledgebase for Q&A(↘︎Link). HLRs(↘︎Link) drive what we are going to build, UAC(↘︎Link) drives what will happen when we build it, and Q&A reflects on UAC. Closing the loop makes not only development but also the business happy. We build what we measure—we measure what we build, ideally with BDD – Behaviour Driven Development(↘︎Link).
This brings us to the following article, which addresses the service design proposition in Figma and examines brother exploration in the business landscape.
In the next article, we’ll look at how to set up a service design environment, why certain nuances of this setting are essential in the beginning, and how these agreements and principles accelerate the company/studio/agency at scale.
Happy scaling through design!
Hey, I’m Jiri Mocicka. A London-based Designer, Trusted Advisor and author of Design at Scale™ – A method that allows individuals to shape the future organisation through design. Grid Magazine – brings weekly articles about product design development. An Online Academy helps designers find their feed in teams of 01, 01, and 100, supported by Supply, which is a collection of digital artefacts that helps you to become a 1% designer.
Have a question or are hesitant to ask – join our Design at Scale™ Community to reach out like-minded individuals who scale design propositions.
