Introducing the Co-op Experience Library

The Co-op Experience Library is a collection of guidelines, tools and resources to help us create better customer experiences at Co-op. It’s the latest iteration of the Co-op Design System, and it’s for anyone working on products, services and communications at Co-op. 

And it’s now open to all, at coop.co.uk/experience-library 

Here’s what the Experience Library looks like

What’s in the Experience Library

The Experience Library includes advice and guidance on: 

Why create an Experience Library

Co-op is made up of many business areas including our Food stores, Funeralcare, Legal and Insurance. And colleagues from each of these businesses communicate with their customers every day through a wide range of channels including websites, apps, email, telephone, forms, in store and in communities. 

These customer experiences (that’s each point a customer interacts with Co-op) must be connected and consistent so that customers understand us, trust us and choose to use our services. So, we want to create a place where colleagues can go to get help building accessible, consistent and inclusive customer experiences.​ 

By creating a central library of reusable assets and guides, we believe that teams can: 

  • create, test and iterate quicker 
  • collaborate and share more easily 
  • save time and money 
  • focus on meeting their customer’s needs 

Why we reinvented the Design System

The Experience Library is the latest iteration of Co-op’s design system. Earlier this year we wrote about how we’d used a brand sprint to kick off the reinvention of Co-op’s design system

We’d spent a lot of time researching the design system with colleagues. And, although we knew it was being used, we found that there were areas we could improve, including: 

  • making it more inclusive for people who were not designers 
  • making it more inspiring 
  • reducing the gaps in design advice and documentation 

So we’ve spent the last few months trying to fix these issues. We’ve: 

  • changed the name to the ‘Experience Library’ to encourage both designers and non-designers to use it 
  • worked with other teams and business units to include a broader range of topics 
  • added more detailed design advice and documentation 
  • established content processes so that anything that gets added to the library is researched, critiqued, understandable and accessible 
  • worked with subject matter experts from around Co-op to feed in and check the guidance 
  • created a new visual language that we hope will inspire people to experiment and build on the foundations within the Experience Library 
  • worked in the open, shared what we’re doing and regularly got feedback from colleagues 

Our vision

We’ve started by focusing mostly on the digital experience. But this is only the beginning, we have big aspirations. We want the Experience Library to be useful for anyone who communicates on behalf of the Co-op. That’s anyone who a customer interacts with, through any channel, in any business area. Our long-term vision is: 

To create and maintain a comprehensive, evolving library of foundational tools, resources and assets that empower us to create better customer experiences across Co-op. 

To do this we need the library to be truly collaborative – the one place where colleagues can go to get trusted and up-to-date guidance that meets their needs and makes their jobs easier. 

So next, we’ll be working with teams across digital, communications and brand to understand how we can better support and collaborate with them. 

Tell us what you think

We’d love to know what you think about the Experience Library. Fill in this form to give feedback

And, if you’d like to stay up-to-date about changes and developments to the Experience Library, sign up to the Experience Library mailing list

The Experience Library team 

Using a brand sprint to kick start the reinvention of Co-op’s design system

The One web team exists to create a platform of tools and resources that all Co-op teams can build efficient, coherent websites on. In September, we reorganised the One web team to help us achieve our vision:

Enable Co-op teams to deliver cost-efficient and coherent user experiences

And, as part of the reorganisation, we finally formed a dedicated team to own our design system (we’d been working on it in the background for 7 years before then).

Starting with research

Part of our work was to look harder at the design system itself. What and who is it really for? How well are we doing right now?

Interviews and a survey told us:

  • there’s lots missing from the documentation
  • designers struggle to know how and when to change something
  • it’s not clear how to design ‘on top’ of the design system to create the right experience for the variety of products we have at Co-op

We’d already begun to address some of these problems by starting to create the documentation for production and process, and by adding new content to a prototype that we planned to iterate internally.

However, the other insights were more difficult to tackle, and linked to feedback we’ve had in the past describing the design system as ‘boring’. But in many ways being ‘boring’ is a good thing for a design system because “The job is not to invent, but to curate.”

We agree with this. Our One web vision is to enable product teams not design what we think is right for them – they know their users far better than we do.

That said, it still felt like:

  • the design system did not inspire enough
  • we were not articulating its purpose very well
  • it did not reflect the values we hold as a design and product community

Exploring the problem with a brand sprint

The customer experience team recently presented a brand sprint they’d run that had begun to define the proposition and design direction for one of our businesses. It inspired me – it felt like a process that could help us solve some of the problems we’d identified.

The Google Ventures article on brand sprints says:

After doing the exercises, the team gets a common language to describe what their company is about — and all subsequent squishy decisions about visuals, voice, and identity become way easier.

The techniques in a brand sprint could help us define a common language we could use to help explain why and how:

  • the design system is good for Co-op and its customers
  • how we ‘do design’ – the values that are embedded in all of our work
  • it is a base for innovation
  • it is for everyone at Co-op – not just designers or engineers
  • it is a community

Doing the brand sprint

We formed a team comprising of the core design system team (design, content, product and front-end), James Rice (who developed the process for us and helped keep us on track) and designers from outside the team to act as fresh eyes and bring specialist skills in visual design and illustration.

The process at a high level was:

  • a 3-hour brand sprint kick off consisting of a custom set of the exercises in the Google Ventures article and using the findings of a survey we conducted upfront to get insight into the values we hold as a community of designers at Co-op
  • a 2-week ‘divergence’ – where we split into 2 teams creating many different concept designs and content directions
  • a series of critiques to identify what we felt was working and what was not
  • a 2-week ‘convergence’ – where we made decisions and worked up final examples of webpages, posters and banners to give a sense of the final direction

Highlights from the 3-hour brand sprint kick off

Personality sliders exercise

The personality sliders exercise showed an apparent lack of consensus on the personality of the design system. What we discovered after group discussion was that we all wanted the design system to speak to people in a different tone depending on what they were trying to do.

The application of design and community content should be innovative and playful, but our documentation should be authoritative, clear, and in some ways conventional.

Defining audiences and sequence of targeting

Our attempt to map and prioritise our different audience groups

We decided initially we would try to create design and content for 2 groups: 

  1. our core users of designers and digital product teams 
  2. senior leadership at Co-op

We want to create something that:

  • designers, know how to use, helps them understand the values of the team and are motivated to contribute
  • helps senior leadership quickly understand the value of having a design system

A culture survey to inform how we talk about culture

We want the design system to reflect our culture, so we sent out a survey to our Digital community to discover what people thought and felt about working on digital products at Co-op. Paraphrasing the results – people said things like:

  • we have a strong culture of collaboration
  • we aspire to be a renowned design team and it’s a conscious goal
  • the design team is here to use design to make things better for Co-op
  • working here is an opportunity to share skills and learn

Anna Pickard sums up what we were trying to achieve brilliantly in her talk: How to make brands sound human

The culture turned inward creates the product. The culture turned outward creates the brand.

Setting a brief for the team

I summarised the outputs into a brief for the next stage, giving closer direction on the audiences we wanted our design to speak to and the kind of outputs we should create. We would create design and content on:

  • the principles of ‘how we design at Co-op’ – for example, how to customise a base design system component
  • community ‘calls to action’ to contribute
  • high-level benefits of why the design system is valuable to Co-op and its customers

Going wide with our design thinking

After the brief was set, we split into 2 teams and spent 2 weeks researching and experimenting with ideas. Here are some of the concepts we came up with, including crit notes from the wider design team.

Converging on a design direction

Finally we took the elements from the diverge stage we felt were working and decided on a set of artifacts that represented how we might apply design and content to different areas of the design system. We created a landing and documentation page, poster, and call-to-action banner.

Below are some snapshots of the work that will set the direction for the design system brand. It’s important to say that this is a direction – we still have work to do to refine exactly how we’ll apply this kind of design and content.

We’ve also been brainstorming names during the process. We feel the name ‘design system’ could alienate some people we could work with in the future at Co-op who don’t consider themselves to be designers. That name also doesn’t reflect the breadth of what will be included. Nothing is set yet, but on these examples you’ll see we’ve been using the name ‘Experience Library’ in its place.

A section on the website that could promote meet-ups

With photography, we’re keen to reflect how we communicate right now while we’re all working from home, and we’ll also be diverse. We design with colleagues from all around Co-op with a wide range of skills and backgrounds. Our Experience library and the photography we use within it should reflect that.

A poster aimed at helping a wider audience understand what the Experience Library is for
A mock-up of what the homepage could look like

What’s next?

We have a pretty well-formed roadmap for the next few months focusing on creating all the missing documentation and the processes that will support this in the future. During this time we will develop the visual language and also create a content strategy focussed on what we want to achieve and how we’ll achieve it, workflow and governance, our personality and tone, and how we’ll measure success.

We’ll be working this design direction back into the prototype and releasing it iteratively internally to our teams alongside the new documentation. Then we’ll be going back to speak to more of our users and getting even more feedback.

Was the brand sprint useful?

The brand sprint process was intense, and it derailed our work on content for a while. But not only has it helped us develop the design language of the experience library and focus even more intently on our users, it’s also given the team a greater understanding of the vision and goals we’re working toward.

We’re creating a place where Co-op colleagues can go to get help creating better, more inclusive customer experiences.​

It’s not just for designers. It’s for anyone working on products, services and communications.

Matt Tyas

Principal (design foundations)

Sign-up to our updates to keep up to date with our progress.

coop.co.uk/designsystem/sign-up

We’ve updated our forms guidance in our design system

We’ve been quietly working on our forms guidance in our design system. It hasn’t been a quick process because the guidance we’ve added so far is based on research. And this takes time. 

Before we added the guidance, we:

  • looked at the data we had – things like error rate, heatmaps, and where customers appeared to struggle across our digital journeys and components
  • identified each type of component that was being used across Co-op’s digital products and services and considered whether each was necessary
  • identified best practice from different design teams within Co-op, and looked at the great work GDS have published 
  • gathered industry expertise from the likes of Caroline Jarret and Adam Silver
  • invited stakeholders to design crits as a way to check that our forms guidance is specific to us at Co-op

We A/B tested our initial designs across certain journeys, gathered more data as a result, and iterated before adding the designs to our design system. 

The forms guidance we’ve added so far isn’t ‘finished’ (and likely never will be). The roadmap below shows we still have much more to research and design and test, but we’re sharing what we’ve done so far.

Why forms are so important 

Forms are one of the most commonly used design components across our digital products and services at Co-op. From both a customer and a business point of view, they are also an essential part of a service because they allow a transaction to take place. At the simplest level, the user adds information into a form so we can help them complete what they came to coop.co.uk to do – whether that be buy groceries, get an insurance quote, or sign into their Membership account. 

In line with GDPR, we also collect customer and member data through forms and use it to improve services. Having a standardised way to collect data across all digital services makes data more reliable.  

The problem: inconsistency across digital journeys 

Before we began this piece of work there was inconsistency in our form design across the organisation. Design teams were creating forms that worked for their specific service and implementing them – sometimes, there wasn’t consistency within forms in a single service. The form type variations were numerous and the time spent designing each must have amounted to a lot. 

I’m a designer in the Digital Experience team in Co-op Insurance. Our aim is to make it easier to find, buy and manage Co-op insurance online. Part of the user journey to get a quote or buy insurance takes the customer away from a Co-op-managed website and onto our insurance providers’ (we call them ‘partners’) sites. 

When we started our research into forms, we were selling 11 insurance products through 11 different partners. Each partner manages their own online buying experience so there are inconsistencies with customer experience (and this will continue to be the case for a while). The customer journey for each partner looked different, and the functionality of individual components like checkboxes varied too. Considering the huge inconsistencies, we do not think it’s a coincidence that we experience a poor ‘customer struggle score’ (one of our key metrics), an increase in drop-out rates and poor conversion.

Of course, we have no control over our partners’ design decisions but when they designed their pages, we didn’t have thoroughly tested forms guidance to point them towards. I hope we can now use it to start to influence them. We’ve done the hard work and it’s in our partners’ interests to use the guidance to create more seamless, usable customer journeys.  

Impact on our users, customers and members 

When we first posted about the Co-op design system back in 2018, we stated one of the aims was to help create familiarity across our distinct business areas. We said: 

The way we communicate with a customer in a food store is likely to be very different to how we speak to a customer in a funeral home. So it’s likely that our services might feel different. And that’s ok, as long they feel familiar.

A design system lets us create this familiarity. It should lead to a much more unified experience when they interact with different Co-op services.

When something feels familiar to a user, it reduces the cognitive load for them because – consciously or not – they know what to expect. And on some level that’s comforting. 

Accessibility is also a huge consideration. It’s something we’ve been determined to get right so we can use accessible components and patterns in our forms across all our services. It’s not only the ‘right thing to do’, it also lessens frustrations for anyone with access needs and reduces the chances of potential customers going to competitors. We know that 83% of people with access needs limit their shopping to sites they know are barrier-free (source: clickawaypound.com). If someone does not have a positive experience with one business area, they are unlikely to return to another.  

Data-driven design 

We made design decisions based on evidence. 

So for example, we used Session Cam to see heatmaps of where users click, hover and scroll and it showed us that when they were choosing an answer from 2 or more options on a form, many weren’t selecting the button itself – they were selecting the label next to it. (On the left-hand side of the image below shows this). This informed the design of our radio buttons and checkboxes shown on the right-hand side of the image below.

Sometimes, we made assumptions based on other teams’ evidence – and that’s ok. For example, at a crit we agreed to use a border for focus, active and hover states so the user would know which areas were clickable. Then we read this post on from GDS which describes why they ended up removing the grey border from radio buttons and checkboxes. As a result we agreed that the area would remain clickable but only highlight the border at hover state. We tested with our own users to confirm our assumption.

The Design System team are taking it from here

We recently put together an official Design System team who’ll be dedicated to taking this type of work forward. They’ll keep you posted on their progress.

Paul Braddock

UX Designer from Co-op Insurance

We’ve iterated our Ways of working site, and we’ll keep iterating

We’ve started to bring together our design-thinking process and some of the methods our delivery teams use throughout the lifecycle of a product or service. They live here on our Ways of working site, which is part of our design system.

screen shot of the ways of working homepage

At the moment, the site includes 13 methods and they’re grouped like this:

Discover. When we’re finding out what the valuable problems to solve are.

Define. When we’re checking we’ve identified the key metrics and business objectives.

Develop. When we create many initial ideas that could address the problems, metrics and objectives.

Deliver. When our ideas are with the users and situations they were intended for – then we can start the feedback and iterate cycles.

Communicate. Working in the open and sharing our progress with the team, stakeholders and users throughout an entire lifecycle.

We’ve taken the first 4 phases (discover, define, develop and deliver) from the Double Diamond – a design process model with years of proven commercial success. We’ve also included methods under ‘communicate’ because working in the open and sharing our work and decisions with the wider team including stakeholders as we go is central to working on a digital product or service at Co-op. 

wow-2

All methods already have step-by-step on how to use them and we’re gradually adding the following guidance too:

  • when to use it
  • why you would use it
  • who and how many people to involve
  • things you may need
  • tips on running the session

wow-3

Why we brought them all together

The methods included in the site have been – and in some cases are regularly – used across Co-op Digital. The site just brings them together so they sit alongside each other as one big design resource.

Our thinking behind it is that having everything to hand, in one place, will be useful to remind ourselves of the range of activities we can try – it can be easy to forget some even if we’ve used them before.

Giving more people more autonomy

The current content was written for digital teams – not necessarily designers but people with a certain amount of knowledge about how digital teams work.

But we know that the site would be really helpful for teams and stakeholders around the business too, in particular those who:

  • aren’t familiar with digital ways of working
  • are less experienced – or less confident – at facilitating workshops
  • are interested in how design can create a competitive advantage and want to find out more about how they can trial the process

The Digital skills team is doing some work around the most effective way to introduce the ways of working site to the wider business. From there, we’d like to understand how helpful it is, and where we’ll need to iterate. This photo shows a team using the mind mapping, crazy eights and storyboard methods.

photo of 7 people around table in a crit

Another more cultural challenge is how we can create the permission and environments to use this process and methods for anyone should they be interested.

Tell us what you think

We think we’ve made a decent start but it’s not complete – we’ll add to it over time. Our next focus is adding more methods that relate directly to user research. Most of the content was written before lockdown when remote working wasn’t the default so adding guidance for when teams aren’t in the same room might be worthwhile.

We recently held a design crit with the Design team but as always, we welcome wider team or external feedback – use the feedback form on the site.

Ciaran Greene
Interaction designer

Building trust in the Co-op design system through weekly hacks

The Co-op design system includes design files – and the coded versions of those files – that help us build Co-op’s digital services quickly and to a good standard.
 

It exists so we can create familiarity across Co‑op products and services, from arranging a funeral to looking up membership offers. Familiarity means that interactions work in the same way and each service feels like it belongs to the Co-op. However, because of our wide range of audiences and user needs they don’t have to be exactly the same. 

Our earlier blog post, Developing visual design across Co-op products and servicesgives a good overview of why this is important. 

How it’s been working so far

For the most part, the design system has done a job good at helping us create familiarity. Every Co-op digital product and service either directly uses the design system’s code, or in the case of our apps its design language. We encourage designers to design for the user needs associated with the specific project they’re working on, and then if we think that part of the design would be useful in another product (such as the format we display a product in), then we’ll add it to the design system.

Designers take ownership of a design pattern. They find out if that pattern is used anywhere else and therefore if there’s a good case to design and build a single version to add to the design system.  

But we don’t have a dedicated design system team

The design system doesn’t have a product team that constantly works on it. It’s a side project that (like all side projects before it) can move slowly, especially against everyone else’s project work. 

Project work quite rightly pushed the boundaries of the design system and in some cases found problems in the fundamental styles that needed to be fixed.  

We found the design system was struggling to keep up. 

Design system debt

Designers were losing trust in the design system for 2 reasons: 

  1. The code was up to date but project teams didn’t want to update as it was a big job to do the update and test everything. Because of this they were writing custom code to try to keep up. 
  2. Design libraries were getting out of sync and people began to create their own versions of the base files.  

But even though our artefacts were getting messy – our products retained a decent level of consistency. We’re lucky at Co-op Digital because we have a collaborative culture so we talk to each other a lot, but we knew that all the extra collaboration, custom code and question asking could be avoided. 

We needed a better way of managing our code

There wasn’t much wrong with the baseline design system – what we call the foundations. It was how we create and maintain and release our code that was the problem. 

The front-end community of practice came up with a solution.

Firstly, we reorganised the code. We’ve split everything into separate files that designers from different projects can just update ‘buttons’ or ‘typography’. We’ve also moved those files into the design system so we only have one source of truth. 

A designer or front-end engineer can now edit a design system component in that single source of truth. Then using a tool called lerna.js this is published as a separate package to NPM.

This means although we have one place to work on and maintain our design system – it’s easy for projects using the system to just use what they need. Some projects only use foundations and some like Digital offers only use a small subset of the foundations and have written custom code to push the boundaries of design toward something more playful. This feels like the perfect balance. The right solution for users – but only the code they need is downloaded to their device.

We’ve introduced design system hacks 

Every week, we bring together a group of designers, content designers and front-end engineers to work through a design pattern: from creating the specification and documentation. This manifests as the finished Sketch library symbol. We build the pattern into the system’s codebase and release it. 

photograph of a design system hack

This is good because we’re: 

  • sharing knowledge on how to contribute 
  • all contributing and collaborating 
  • all learning about each other’s disciplines 
  • keeping the design system up to date  

It also means that we carve out time to actually do the work. In the past this wasn’t happening because when you go back to the day to day pressures of your project – the design system is easy to push to one side. 

The Co-op design system will never be ‘finished’ – it’ll continue to be led by the projects across the organisation. We’ll just be regularly dedicating time for its maintenance from now on.

Matt Tyas
Principal designer

We’ve added user research guides to the design system

We recently added 4 user research guides to our Co-op design system. The guides cover:

  • how to plan and prepare for research as a team
  • how to choose the most appropriate research method, and how to use it
  • how to analyse your findings, turn them into something actionable and how to share with the rest of the team
  • a list of useful research tools

We’re committed to user-centred design. We start small, we test for user value and we work iteratively – research and reacting to feedback is vitally important to us.

But it’s not easy to do good research and by ‘good’ we mean using the appropriate method and ensuring the way we do it is planned, thorough and unbiased.

You need skilled researchers.

Helping teams help themselves

We have a superb small team of researchers at Co-op Digital. We have varying background, skills and strengths which means asking for advice on how to tackle something is always interesting and useful. But we can’t cover all our projects, at all product phases, all the time. There aren’t enough of us.

So in a few cases, we set the direction and encourage teams to do their own research, with us there as support.

Sharing the knowledge

The idea came while I was writing a research strategy for a team working on a particular scope of work. I realised the strategy could be adapted into more of a ‘how to do research at the Co-op’ guide. For years, in an unofficial, internal-channels-only type way, several researchers had been writing guides on things like ‘how to recruit users / gather informed consent / write a survey’. It made sense to pull this useful work together and make it open and available in our design system.

Presenting guidance in this way means that instead of individual researchers writing a strategy for a team now and then, we can give more general advice.We want to make sure people are doing good, useful research in the right way and we can now add value to any digital team by giving them a ‘best practice’ resource.

We’re working on it

As always, the plan is to iterate and add more guidance as we go. We’ve been looking towards the GDS service manual as an excellent, detailed resource for planning research.

As we come across a method that we don’t have a guide for, we’ll write one up. For example, the next time one of our researchers needs to conduct a diary study they’ll write that up.

We know we need to improve how we help people choose the appropriate method so that people don’t just fall back on conducting usability testing in a lab or face-to-face interviews. As Vicki Riley says in her post, matching our research approach to the project is really important.

We’d like your feedback on it too so if you have any, leave a comment.

Simon Hurst
Lead user researcher

From digital design manual to design system

In January 2017 we released our digital design manual. Now, 18 months later, the design manual has evolved into a design system.

Although it’s been live for months, it’s still (and always will be) a work in progress. We’re sharing it now in line with one of our design principles: ‘we design in the open’.

You can see the Co-op Digital design system at coop.co.uk/designsystem

Evolution of the design manual

The aim of the design manual was to help teams release things faster so they could focus on user needs rather than on making basic design decisions. We iterated and added new pages as and when there was a need, for example, we added guidance on forms, guidance on tables and our secondary colour palette.

But a year after its release, we were at a point where more of our digital services were going live, so we revisited the design manual and asked if it could be more useful.

What we learnt from our users

We asked our design, content design and user research community how well they felt the guidance in the design manual was serving its purpose. Feedback was mixed but most people felt that it didn’t quite cover enough.

A workshop made it clear that users wanted:

  • example-driven patterns
  • guidance on when to use specific design and content patterns
  • examples of ‘experimental’ patterns
  • all guidance in one place

Afterwards, we dedicated time to making some major changes to the content as well as the navigation and layout.

Design system – nice for what?

We found lots of excellent examples of design systems in our research but good, solid design systems are good and solid because they’re unique to the organisation or business they belong to – they meet the needs of designers, content designers and researchers who work there.

The Co-op Digital design system includes our:

  • pattern library
  • content style guide
  • guidance on our design thinking
  • design, user research and content design principles
  • tools (front-end and prototyping kits)
  • resources (Sketch files and brand assets)

Most importantly it’s a living document. Like all good design systems, ours will never really be ‘finished’ but it’ll evolve as our teams and services do. Over the past 6 months we’ve established processes that allow our team members to contribute to the system.

We audited our existing design work and looked for similarities and opportunities to create familiarity. We’ve also spent a lot of time building the foundations for a stronger and more collaborative team through workshops, design crits and making sure we design in the open.

Familiarity over consistency

The Co-op is an organisation with very distinct businesses which all need to communicate with Co-op members, customers and users in an appropriate and relevant way. For example, the way we communicate with a customer in a food store is likely to be very different to how we speak to a customer in a funeral home.

So it’s likely that our services might feel different. And that’s ok, as long they feel familiar.

A design system lets us create this familiarity. It should lead to a much more unified experience when they interact with different Co-op services.

Pattern library

We’ve started creating a library of design patterns – this is the most significant addition to our previous guidance. It doesn’t replace our design guidelines, it just pulls out the useful stuff we learnt designers look for when they’re designing a service. 

Each pattern will have:

  • an example, ie, a visual example of the pattern
  • an associated user need
  • design guidance, ie, how you use it
  • accessibility guidance

Our colour palette pattern is a good example.

The library will be the de facto standard for how we display certain types of information.

Anyone at Co-op can contribute by submitting their pattern to the design community. They can do this by filling in a form justifying why users outside their service might benefit from this pattern or, why what they have created is an improvement on a current one.

Evolution of the design system

We want to continuously improve the guidance designers are looking for. To help us do this we’ll speak to more of the external teams that work with us and invite our colleagues in the Brand and Marketing teams to contribute their own guidance. We’ll also put the system to the test with teams as they build more Co-op services.

Watch this space.

Jack Sheppard
Matt Tyas