# One product, several surfaces - Type: Case study 02 - Company: SharingCloud · Workplace management - Period: 2022 – 2025 - Role: Principal Product Designer - Team: Two Product Owners, three front-end developers, a Scrum Master - Deliverables: Multi-surface redesign, design system - Status: published - Related content: - [Essay 05 · Several interfaces, one product](https://florianbutour.com/en/writing/several-interfaces-one-product.md) - [Essay 02 · The model before the screen](https://florianbutour.com/en/writing/the-model-before-the-screen.md) - Web page: https://florianbutour.com/en/work/workplacetobe WorkplaceToBe had to remain a single product while being delivered on several surfaces: web, mobile, Outlook, room displays and desk labels. I led its redesign on the design side by building a shared system, able to adapt the same uses to each context. SharingCloud published WorkplaceToBe, a workplace management platform for booking spaces, declaring office presence and following life on site. I joined the team in 2022 as Principal Product Designer to lead the redesign with two Product Owners, three front-end developers and a Scrum Master. I also mentored a work-study designer. ## A product that had become fragmented WorkplaceToBe had been built through successive additions. Over time, its interfaces had accumulated different components, behaviours and sometimes technologies. So the problem was not only visual: without a shared foundation, every new feature or new surface deepened the fragmentation. I proposed starting **with a shared design system, with the support of the front-end developers**. Fig. 01 · From juxtaposed additions to a shared foundation: before, each surface brings its own components; after, four shared levels. : Before · Each addition brings its own components. · Web · Mobile · Outlook · After · Patterns carry the unity, libraries the differences. · Library · Web and mobile · Library · Outlook · Library · Screens and labels · Patterns · book, declare presence · Components · buttons, fields, icons · Tokens · colours, typography, spacing ## Starting again from uses Rather than treating each interface separately, we went back over the product’s main uses: - **Booking**: room, desk, parking space, bike or locker. - **Presence**: declaring your office days and seeing where your team is. - **News**: following life on site. - **Events**: seeing what is happening on site. This reading made it possible to see Outlook, room displays or DeskTags not as standalone products, but as **specialised access points to WorkplaceToBe**. ## Shared objects The data model already existed on the back end. My work consisted in identifying the objects users actually handled and giving them a consistent representation in the interface. A booking, a space or a presence had to keep the same meaning, the same vocabulary and the same essential information, whatever the surface. Fig. 02 · The objects as the interface presents them, read as sentences: space comes back in most uses. : Site · a building · → contains · Floor · its zones, its plan · → contains · Space · room, desk, parking, bike, locker · Person · an employee · → makes · Booking · a space, a time slot, a person · → concerns · Space · room, desk, parking, bike, locker · Person · an employee · → declares · Presence · at the office, remote, absent · Team · who is at the office · → groups · Person · an employee · Site · a building · → publishes · News · and events, per site ## One use, several contexts Web and mobile formed the core of the product. The other surfaces only took on the uses relevant in their context. Fig. 03 · One use, several contexts: each use only appears on the surfaces where it makes sense. : Book a room · Web · Mobile · Outlook · from the invitation · RoomPad · at the room · BoxPad · Book a desk · Web · Mobile · Outlook · DeskTag · occupancy · Parking, bike, locker · Web · Mobile · Declare presence · Web · Mobile · Outlook · See your team · Web · Mobile · Outlook · News · Web · Mobile · Events · Web · Mobile · full use · information only · A surface missing from the row does not offer that use. So a feature was not duplicated everywhere on principle. It only appeared where it made sense: booking from Outlook, acting directly at a room, or showing who occupies a desk. ## What stays shared, what changes The design system shared **tokens** (the named values for colour, spacing or typography), components and interaction patterns. This foundation was adapted into libraries specific to each surface. Three rules guided these adaptations: 1. **Objects and vocabulary stay the same.** 2. **Interaction adapts to the context and to the available density.** 3. **A new surface exposes existing uses; it does not recreate the product.** We identified the shared uses, then kept for each surface those relevant in its context. Booking a room from an Outlook invitation and doing it on a RoomPad at the door are the same use, but different situations. The room display was not meant to take on all the day-planning features available on the web. ## Result and scope The new web home brought the main uses together around the employee’s day: their bookings, their team’s presence, events and news from the site. WorkplaceToBe home screen, web and mobile WorkplaceToBe on-site screens: RoomPad outside a room, BoxPad free and occupied, desk labels The redesign established a shared framework for evolving the interfaces: shared objects, identified uses and adaptation rules. This framework was meant to limit the decisions revisited for each new surface. The case does not, however, document any measure of design time saved or any comparative evaluation of the experience across surfaces. SharingCloud was [acquired by Witco in June 2024](https://www.witco.io/fr/blog/witco-acquiert-sharingcloud-et-renforce-son-leadership-dans-les-solutions-smart-office). This work is representative of how I approach this kind of product: **start from uses, stabilise the objects, then adapt their representation to each context.**