Design at Co-op plays an important role in solving users’ problems and Co-op achieving its goals. We advocate for user-centred design, accessibility and a full-service view as key to Co-op’s success.
The design leadership team are made up of 2 Heads of Design and 5 Principal Designers. We cover our Co-op businesses and colleague facing services, manage our large team of designers, and push forward our core design disciplines. These are interaction design, user research, content design, service design, CRO (conversion rate optimisation) and SEO (search engine optimisation).
In its current form the design leadership team has existed less than a year. We’ve been busy forming teams, building relationships and delivering for the Co-op businesses, our members and customers. We’ve been sharing challenges and supporting each other, but not spending enough time together working as a group. We needed to focus on why we exist, what value we can add to the design team and what we want for the future.
We reflected on our purpose by taking part in a workshop
It was important we took a step back and came together, because as a team, we should have a purpose we align on and can refer to. Our purpose is for our group – it’s not a design strategy. Design strategy is related and part of the wider goals that we share with other digital colleagues.
Our purpose is a way to focus on the things that are important to us and how we want to grow and enable the design team.
What we did
The workshop (devised by Imran Afzal, our Interaction Design Principal) was split into 6 parts and helped to guide the group towards creating a purpose statement.
Thinking about our values
We discussed the unique qualities we bring to the team and the values we hold. We grouped these into themes.
Discussing our shared history
We took the time to understand each other and the events and influences that brought us together. This gave us a shared empathy for our individual stories and motivations.
Designing leadership posters
We created posters that described the role of leadership in the design team. This helped us visualise our shared challenges and our goals.
Defining our team purpose
We defined our purpose by asking:
why does our team exist?
what is our motivation day in, day out?
what are we trying to achieve long term?
how does our work make the world better?
Bringing our purpose to life
We considered how we might bring our purpose to life by asking:
what behaviours will bring our purpose to life?
how can we bring our purpose into our day-to-day work?
how can we serve our purpose better?
how can we inspire others around our purpose?
Our purpose statement
“The Design Leadership team enable designers to make meaningful change”
Breaking that statement down, we intend to:
enable our design team to succeed by helping them to grow in their careers through developing their craft and themselves, and making sure they have the confidence to innovate and challenge in the ways they work
ensure we design in a way that is meaningful, creating the conditions where ethical, accessible and sustainable user-centred design can flourish, in turn benefiting our users and the Co-op
Alongside this we made a set of commitments and behaviours that would help to drive this purpose forwards.
The commitments that design leadership made are to:
try things and be bold
increase design literacy across disciplines (outside of design)
share our vision for the future of design at Co-op
have challenging conversations
define ways to measure design value
share our story (failures and successes)
The behaviours that design leadership will display are:
We haven’t changed how we think about design by doing this. Much of it we already do quietly, and our objectives align to these commitments, behaviours and purpose already. However, by saying it out loud, we have a reference point to guide us as well as a benchmark to ensure our team’s future and culture can be measured.
We’re already working on objectives that align to our purpose. We’ll remain open as we keep working.
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.
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
We decided initially we would try to create design and content for 2 groups:
our core users of designers and digital product teams
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
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.
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.
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.
We created several tools and functionality along the way to make us more efficient including:
a consistent technology stack that took 50 minutes to set up – rather than 4 weeks
a set of shared front-end components that allowed each website to have a set of consistent design patterns available to it
We proved the value in our approach. Our websites were no longer reliant on third parties and inconsistent (and often unsupported) technology. The user experience and user journeys were improving, and we were seeing our metrics improve.
However, as a successful team grows to meet delivery demand, we found it difficult to keep working in exactly the same way.
The problem: we got big
Digital transformation often takes a long time. Although we had the websites in a much better place, the Digital team and businesses areas across Co-op were still busy building the right capability to support and iterate their user experiences.
This meant the Web team was suddenly supporting and trying to improve multiple things at once and we were finding it difficult to improve the core parts of our platform that had made us successful in the first place.
The team got bigger and bigger and we could no longer work together on one thing as a single unit. We had multiple requests coming into the team meaning we fell into some classic traps of not knowing why we were doing certain things and what their value was.
This made it increasingly hard to deliver due to the amount of work and interdependencies between people and systems.
The solution: smaller, focused delivery teams
The team kept scaling to help meet demand but had had very little time to reflect on and analyse how we organised ourselves internally. We could all see the symptoms mounting up and in January 2020 we did something about it.
We made a clear statement to our leadership that to add the highest value to Co-op and its customers we needed to stick to our vision.
It was the responsible moment to begin handing work to the business areas that should own it. For example, the digital team in our Food business should own and be able to iterate coop.co.uk/recipes in line with their strategy and users’ goals – after all, they’re the experts in that area.
The Web team could then regain its focus and enable teams by delivering solid foundations of technology, shared functionality and design patterns. This allows all digital teams to move faster and spend more time focusing on meeting the needs of their users – not on fixing the basics.
How we’ve restructured our teams to help us achieve our vision
We split our team into 3 to help us deliver effectively on different areas of our core product. We call these teams our ‘Web platform’ teams. They build the features, tools, resources and standards to enable other teams to focus on their users.
We now have:
A design system team
Focusing on providing the solid foundational tools, resources and standards to enable other teams to work fast – with quality baked in from the start.
well-tested design components with usage instructions
a framework for testing accessibility at a component and user journey level
a community lead contribution and maintenance process
A ‘coherence’ team
This team provides the tools so that other teams can build and maintain their products and services themselves rather than relying on us to build for them and provide ongoing technical support. In other words, we help make sure the user experience is coherent.
An ‘efficiency’ team
Ensuring every tool and framework provided by the Web team is efficient, robust, secure, and works for everyone. We want to enable every team to deliver faster.
We also have 2 other pre-existing teams in our area, that we call our ‘enabling teams‘, these teams work with business areas that are utilising the web platform. These are:
The onboarding team
This team helps our partners across Co-op to move their website to the web platform.
The Conversion rate optimisation (CRO) and search engine optimisation (SEO) team
This team provide specialist services to partners all across Co-op in the CRO and SEO areas.
We’re excited about the future
There’s been a lot to sort out to allow us to get to this point and we appreciate the patience of our stakeholders and colleagues as we’ve made the changes.
We’ve been working in our reorganised teams for 4 weeks now. Each new, smaller team has its own roadmap, goals and focus, and we’re feeling positive.
We’ll post about how the new arrangement is working out soon.
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.
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:
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.
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.
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.
There are actually 3 things that help us design digitally:
Design manual: our guidelines on digital design.
Front-end toolkit: the Sass (CSS) that gives the design manual and our services their base look and feel.
Prototyping kit: that allows designers and developers to quickly test and iterate services.
The design manual can help if you:
design or build digital services at the Co-op
write digital content for the Co-op
are checking if a service meets the standards, matches our design principles and the Co-op’s values
We want the design manual to:
help teams release faster and focus on user needs rather than spending time on the basics
help document what we learn from research so we apply it in our work
be a collaborative document that is widely and regularly contributed too
The design manual isn’t a set of rules, it’s a strong backbone for our digital services. It will change in line with learnings from user research, the changing business landscape or new technology. The design manual and its assets are the starting point for designers to design, not paint by numbers.
What we’ve done
Reworked our basic design system
We’ve actually removed quite a lot from the style guide. At least for now anyway. It’s ok if a service still uses these things but we want evidence of how they’re working for users before we add them back in.
Some of the changes we’ve made are:
We reworked our typography
What we had worked well for our printed material. But, it needed to be bolder and more flexible so it’d be suitable for different devices and have a better vertical rhythm (the vertical spacing we use between text and other page elements) to make it more easily legible on screen.
We added guidelines for writing for Co-op
Writing for digital is different to writing for other mediums. It’s about finding and doing things quickly — getting maximum meaning into minimum content.
Our principles help to align ourselves around some central ideas that will guide our future design decisions. We’ll be writing more about these soon.
We’ve given it a new name
It’s now called the ‘design manual’.
This signifies a move away from ‘rules’ about design elements, to evidence-based advice on how design patterns are used in combination to create compelling digital services. This advice will evolve as we learn more about what works for the people who use our services.
What does this mean for our current services?
As a favourite quote of mine from information architect Abby Covert says:
You’ll start to see more of Co-op’s digital services sharing this updated design language creating consistent experience across the wills service, Membership, co-operative.coop and coop.co.uk. We don’t expect every service to suddenly shift all of their design work over to match the updated design language though. Instead, you’ll see a more gradual iteration as services adopt the updated styles – something many of our designers are already doing.
Most importantly we want to iterate and release much more often. This is an extra part of everyone’s job so keeping this momentum up is always the challenge.
create a more visible backlog of upcoming improvements based on user research and live services
put in place a clear way for colleagues to feed into the design manual
look at what our shared design language for more complex design elements should be
communicate changes to the design manual effectively and widely
add more guidance about writing for Co-op
find a way to host and link to user research from design elements
develop the user journeys and information architecture for users of the design manual
link to live examples of design patterns in use
create a more simple HTML and CSS template for developers
continue to refactor and improve the front-end tool-kit
do ‘show and tells’ on each release
Finally, a thank you
Creating and maintaining a strong design system is not easy. It requires a lot of buy-in from an organisation and a lot of extra work from its contributors. With cooperation being at the heart of what we do it’s no surprise that I’ve had this from all the service teams, business units and senior leadership I’ve worked with as well, of course, from the design team. Thank you to everyone – too many to mention – who has been involved so far.
The design manual will continue to grow and evolve as our services do. You mark my words.
I realised that a huge proportion of my working year has been devoted to helping create a new design language for the Co-op and I had quite a lot to say on the subject. This therefore, will be the start of series of posts charting how we are tackling prototyping and (more widely) design at the Co-op.
A while ago the focus in the design community shifted from designing pages to designing systems. Using modular, reusable components that together fit any shape or size while retaining usability and brand aesthetic. We weren’t selling paintings anymore. We were creating living systems that must fit a variety of user needs and contexts.
I became aware of this way of thinking from Nicole Sullivan’s much cited article about the ‘Media Object’. She noted that the same design pattern was built many times over using the same code. Repeated many times, by many different developers. The idea that a design pattern could save thousands of lines of code I found interesting. Most noticeably, it turned me into a pattern hunter. Constantly looking for ways to save time, code and create more and more consistency in my designs.
Cut to the present day, and many large companies have adopted (and many open sourced) their design systems. Experts within the design community have evangelised their usage at many industry events. Designers and developers have adopted these practices. And the benefits of this approach have filtered down to our stakeholders. In fact at Co-op, we were doing it a long time before the logo changed.
Reasons why designing this way is good:
Every project starts from the same well researched baseline
It promotes a few (researched ways) of doing things that are documented
All components are shared and can be improved by anyone
Designing and building services is faster, cheaper and more consistent for users. As the library of components grows so does our knowledge about their usage
It is agile. By being subject to constant testing and iteration (things can and will change over time)
Things are allowed to be just functional, in testing or even a bit wrong. As long as they serve a user well at that moment. Things don’t always have to be pretty straight away
Because of the above, it allows the flexibility to launch services when we need to and test them in the wild
Challenges we face as a large organisation at the beginning of this journey:
Creating an active community with an open dialogue
Engagement from graphic design through to (at least) front-end developers
Input and iteration based on user testing (and keeping that pipeline flowing)
It not feeling like extra work but part of everyone’s day
Everyone taking ownership
Not having opinion based discussions
Designing ‘marketing’ patterns where needs are less clear cut
Agreeing on naming conventions
Keeping track of everything that gets designed, built and ensuring it is of a high enough quality
Let me tell you where we are now (and answer those questions)
Firstly, we do prototype. We prototype a lot. Very early on we began to translate our colours, logo and typography into HTML and CSS. This was so we could build Co-op branded prototypes quickly and easily. This was the beginning of a Co-op design system. We’ve had a few goes at it, trying this and that. Building things, then rebuilding them in another way to find what worked for us.
Currently, we have a SASS framework. This is the basic code that creates a Co-op look and feel. It can be used as the base for all our projects. We also have a prototyping kit (that imports the above) built on Jekyll. It allows someone with a small amount of basic HTML knowledge to build a simple prototype. It also means we can keep our snippets of HTML and SCSS organised by design pattern. In the world of the web this is all very basic, but the simplicity lowers the bar for entry and will allow us to introduce more and more colleagues to code. Some of our teams will need to prototype by injecting real data, or perhaps build a native app. Whatever they do they can do it from something that is built on standard web technology that will work for everyone.
The Co-op design system is still growing and maturing. Most recently starting to need to contain other wider guidance on content (writing for the web) and user research. We are starting to understand that as a team creates more and more good design this needs to be worked back in to our base system. When a team feels it is ready, it is up to them to set up a review where we can decide whether it’s time to include their new patterns and code. We’re looking for researched, best practice design patterns that work well for real people. I make the comparison in this article to the way we would code these patterns as it helps me understand the methodology, but really these patterns are about great design. We want to create a Co-op design library that promotes best practice usability throughout all our services.
Secondly, yes. We are on Github. For those who do not know, Git is a technology that allows us to store many versions of an application’s code safely and securely. We’ve been on it for a few years in fact. However, in the last few months I have never seen so many exciting new code repositories popping up. When our products owners are ready to talk about their service, you can bet they will. Right here.
We’ve started on our journey to creating a design system that we are proud of, will never stop changing and, in the future will be open source.
A style guide is an artefact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. Nathan Curtis
That’s the dream.
Questions, comments, help or jobs at CoopDigital – I’m happy to say hello and have a brew.
At The Co-op we want to give all our users the best web experience possible across all our websites. Some browsers and devices are used by more of our users than others and that’s how we choose which ones we’ll support.
We have two levels of support, ‘full’ and ‘partial’. For desktop browsers full support is over 3% usage, partial 1%. For mobile and tablet (due to the fragmentation of the market) full is 2%, and partial 1%.
What do ‘Full’, and ‘Partial’, mean?
All the content must be readable, usable and all functionality must work.
The content must be readable and usable. The navigation must work and other functionality must employ graceful degradation. Graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in modern browsers, but it will also degrade gracefully to a lower level in older browsers.
Not all browsers and devices display websites in the same way and we do not look for pixel perfection. By following our support rules we know that all our websites will function for our users and can accept some variation.
Our full support table
An overview of Co-op supported browsers
8, 9, 10
Google Chrome latest (Two most recent versions)
Mozilla Firefox latest (Two most recent versions)
Mac OS X
Safari 6.x, 7.x, 8.x, 9.x
Safari 5.x (Safari in-app)
Google Chrome latest (Two most recent versions)
Mozilla Firefox latest (Two most recent versions)
7.x, 8.x, 9.x
Note: Windows Phone, Blackberry and Opera are unsupported due to low traffic levels.
We want to keep improving
We’re constantly listening to our user’s needs to help improve our products. Our browser and device support information is no different. We used to include a lot of device specific information such as, models of phones and tablets and even had a third level of support that meant ‘no support’. We have removed that information and re-designed the table to make it clearer for the designers, developers, researchers and testers who were using it.
We update our support table every three months based on our user analytics, this is the first time we’ve published this information, and we’ll keep doing it as support changes. Updates normally follow market trends (like the shift toward browsing on mobile and tablet devices) but if a particular service required we support something not mentioned here, we would support it, if it was the best thing to do for our users.
In June 2014 I took a job at The Co-operative as a UI Developer. I was the only UI Developer in the company (I’m a coding designer, when I was a lad we were called web designers) and one of only three Designers. I had my interview at the time when articles like this were in the news on a weekly basis. Now I can’t claim that I knew digital would become the cornerstone of the Co-op’s rebuild programme, but what I did know was that I’d seen in-house digital work and, within this small team of dedicated Co-operative folk was an opportunity to do something positive with my skills.
I’d had a varied enough career up to that point, a mix of agencies, successful side projects and one particular in-house role that changed the way I viewed the industry, designed, wrote code and collaborated. For three years I worked with some inspiring, challenging and career defining people at Leeds University.
At Leeds we were a small team of around 16. A split of developers, and designer / front-enders; it was a perfect storm of talent, passion, friendship (sorry, you can be sick if you want) and just enough ego that we thought we could actually make changes in the leviathan of higher education. And actually, we did. Launching sites like Leeds for Life the Leeds HR website (directly influenced by one of the early alpha.gov.uk iterations), and, most recently, (and after my departure) the Leeds.ac.uk main website (although I can’t tell you how proud I am that I originally prototyped the responsive logo).
More than a little influence taken on the HR site I built…
The point is, a small, dedicated in-house capability launched those websites, based on user needs in an environment where digital innovation or, digital anything was not top priority. I tried other career avenues, but it quickly became clear that it was in this kind of role in this kind of team where I felt I was most effective.
Cut to Co-op
In my first year at Co-op I learnt a lot about selling the work you do and being the voice of it’s merits. Phil and Jack were/are great team mates and together tackled large and complex UX and front-end builds, starting with needs, working agile and building out. We were making a small, but effective dent on the digital experience of our customers in a challenging environment.
But honestly, that’s where the fun is, isn’t it?
Well it is. Every project you push over the line might not be exactly as it was planned and might have be subject to constraints of time, budget, resource and been integrated in a big castle you are not allowed to enter, but each time you learn. Each time you find a way to get some user value in there you didn’t the time before and each time you might change another mind into thinking that your way of working might not actually be so… crazy. Now if you don’t call that fun, you can certainly call it rewarding.
That was then, this is now
That was the case and for all the ups and downs I enjoyed it. But after the hump comes the pin prick of light. And a little while ago our pin prick at Co-operative started to expand.
Two things that happened. Firstly, the rebuild plan. Thanks to the great work done by Phil, Jack, the Digital Team and it’s leaders, the humble UX team was selected to be working on some very important aspects of the rebuild digitally. Around this time too, I was made UX Manager when Phil left and I got more than a little excited about the prospect of leading a little piece of this change for the good. The UX Team has started to grow, we’ve taken on a few very talented people in a short space of time and we’re learning to work and collaborate together. I’m starting to feel the magic of that teamwork from Leeds, and from my early Co-op months again.
It’s not all easy, I have been learning a huge amount every day and making mistakes, but I am lucky that I have great mentors and a team that are enthused with the challenges we face.
The second thing that happened was the announcement that the leadership team from GDS were joining The Co-operative to help with our Digital transformation. The guys who’d done the same work I’d followed the progress of over the last 5 years, seen a conference talk about from Paul Annett and Tim Paul in 2012, were coming to the 11th floor.
Best iron a shirt…
In the two weeks leading up to the announcement we’d been working alongside the new team and starting to work in a way that feels more natural to me. Inherently co-operative – stand up and talk instead of sit down and email. Sketch it and show it, then build it, test it and learn from it.
In the very first weeks of this journey it does seem to me that this little opportunity, and this little team could grow into something very interesting indeed.