Wipros had been working in waterfall fashion to design and build screens for a new product for their client, RSA. While this approach maintained a form of structure and maintenance within the project up to now, there were signs that they wouldn’t be able to meet build deadlines without drastic action. This meant that – without a more agile process being put in place – designers would continue to create screens in isolation, and developers would fall behind.

Designit was given the opportunity to support Wipro by consulting and integrating design implementation best practices. Our focus was to re-organise the design team in a way that supported a smoother transition from design to build, steering them away from a waterfall approach which was doomed to fail.

Design system organisation

We produced design system foundations that aimed to systematise the current messy design file. This includes colour, typography, spacing, effects, and icons. We also organised these foundations into repeatable styles that were embedded into the design file itself. All this with the aim to integrate this setup within Wipro designers’ workflows.

Streamlining the implementation process

Wipro’s current design implementation process was linear and inefficient. The approval and handoff process was often siloed, which led to multiple sign-off sessions that were unfocused. We proposed an updated model that removed unnecessary steps and mitigated the need for extra software.

Defining a governance process

Alongside the updated implementation process, we defined a design system creation and governance workflow. This included levels of ownership, output expectations, sprints, component requests, and an immersive collaboration strategy.

The initial ask was to “clean up” the design file

Before I was assigned to the project, Designit laid some groundwork establishing communication with the client, and understanding the brief. The initial ask was to support in the creation of a component library that the Wipro design team could use to meet design implementation deadlines. This was with the aim to work towards a design phase deadline, whereby the build work streams would all be in full force (leaving no more room for design work). However, the Wipro team was in no state to be inheriting a new design approach.

I took initiative and gave some structure to the disorganised design team

As of now, the design team had been reporting to a technical lead who’s job it was to meet “waterfall-like” deadlines. This meant that the design file for the insurance forms was set up with little to no logic. I.e. the designers had inherited a loose style guide from a previous agency, were not given the space to turn those styles into a defined system, and had to meet ongoing design debt. As I was tasked to “consult,” I set up daily standups to find areas of inefficiency, and connected with developers to understand their landscape.

We needed stakeholder buy in, otherwise dev leads would turn a blind eye

At this point, it was clear that the project had not been set up correctly to involve the supporting a of a single UX designer. However, I did my best to provide value under the increasingly obvious constraints. So, I set up an “Intro to design systems” to both educate stakeholders on the value we could bring (in a more manageable scenario), and to understand how much value we were likely to bring. Turns out – whilst most people were on board – there was little to no follow up the people we needed: Dev Leads.

Project owner wanted a clear direction of travel

Off the back of this presentation, the project owner wanted a view of how much design system work we could provide, and how long it would take. So, we put together a fairly loose timeline that covered phases or work, resourcing, and task expectations. We agreed to utilise two of their designers and myself to produce a set of design system foundations that the developers could then use in the quickly approaching build work streams. This was the compromise we had to reach under a messy, disengaged, waterfall process.

I tried my best to engage leads, and built motivation in the team

But it was too little too late. The project owner began rolling off design resource without contacting us. The best I could do at this point was to continue to communicate with engaged developers with the foundations I was building in Figma + send across a guide on how to make best use of them.

The final output

Design system foundations were set up with best practices in mind. Colour sets were defined, covering brand, semantics, and shades. Typography was re-organised to match the original style-sheet and various levels of hierarchy. Spacing values were defined in accordance with an 8 point grid. Finally, icons were defined into various sizes and colours. This was all consolidated into a set of styles that the developers could access and apply to their code. No need for scattered stylesheets, global styles, overriding, different asset formats etc..

What we learned

Inheriting a waterfall process is tough -

Off the back of some internal changes, Designit LON were looking to go for larger clients on longer implementation work. Whilst this was great, we were not set up to support on a way conducive to this kind of work. There were many challenges that we uncovered as we began to engage with waterfall processes. Next time, we’re a lot more well set up to propose larger teams withe various of levels of seniority to tackle said processes.

Find the joy in the little things (team motivation) -

Whilst I did feel like like a fish out of water at some points, I grew a strong relationship with my little design team and felt inspired when leading them through the difficulties they had inherited. Whether it was up-skilling them on Figma, understand their pains, and achieving small gains.