Digital Marketing & Communications

We've seen 1s and 0s you wouldn't believe

Exploring new ways of writing about our research

📥  Communication

One of the most common content types we currently use for our research content is a press release. Or a news item, which is what we call them after slightly repurposing them for the website. In the past three months, we’ve published roughly 40 research-related news items.

The thing about press releases is that they are tied quite heavily to two very specific points in the research lifecycle - winning a research grant and publishing a paper. Similarly, case studies, of which we’ve published six in the past three months, are tied to a particular point in the research project - to complete the classic case study structure, the results of the research have to be in.

Softer, narrative content

The new content we’re suggesting moves away from all these time-related restrictions. It places the emphasis away from published papers and research results. The story becomes about the researcher, their journey, personality and aspirations. The style of writing is softer, more narrative.

This is a result of a Digital research content strategy we launched in late 2015. It sets out how we want to develop the way we communicate about our research online to reach new audiences and make most of all the cool research that’s happening at Bath.

We recently published two of these kinds of stories. One of them is about an ambitious Syrian researcher who’s on the brink of finishing his PhD with a promising career ahead of him, potentially in a leading international architecture company. The other one is about how one of our senior researchers came to be the host of the UK’s beloved annual Royal Institution public lecture series.

The first one was written by me, the latter one by our Research Marketing Manager Andy Dunne. We edited each other’s articles and various team members were involved in polishing and proofing. Publishing each one felt like a genuine team effort!

Off to a good start

The early analytics of the new kind of content look very promising. Looking at the pageviews of our research content in last three months, the story about the Syrian researcher is comfortably the most popular piece of editorial content we’ve published. The news item that comes closest has over a third less pageviews.

The article about our researcher hosting the Christmas Lectures is in the fourth spot after an old case study about some of our most well-known research (consistently one of our most popular pieces of editorial research content), and a news item about a clinical trial of our smart bandage prototype. That one was published in late November while our feature article was published on the 21 December, so I’m expecting the feature to rack up some more views in the coming weeks.

Why I like it

From a very practical point of view, the best thing about this new kind of content is its longevity. While news items act as a useful reference back to a specific point in time, the feature-style content stays topical for much longer. It’s a far more natural type of content for reusing without edits - whenever a relevant news story arises or a new research paper is published by the academic, it can simply be tweeted or pinned to the landing page of a department as it is.

A nice additional bonus in the process has been seeing how well this content fits into the new templates of Compared to the old templates, the user experience as a publisher has also been top notch! It’s been super easy to upload and publish these.

On a personal note, I really enjoyed the process of interviewing and writing. As an Editor, it’s rare I get to be involved at that stage - my job’s more planning, delegating and subediting. Getting to meet the researcher, listen to them passionately talk about their work and trying to capture that passion in the copy is a process I sometimes miss from my journalism days.


Worldwide: the journey so far

📥  International

Shipping the third edition

Before the Christmas holiday, we launched the latest edition of Worldwide: the end-of-year review. It was the time of the year to look in the rearview mirror and celebrate what Bath has achieved throughout 2016.

The Collection page curates 11 stories covering Bath's achievements in research, student experience and sports, including groundbreaking research projects, Bath athletes' participation at Rio Olympics, how students have fulfilled their dreams, and the celebrations of our 50th Anniversary.

After the launch, we promoted the page and individual stories over the 12 days of Christmas on the University's social media channels: Facebook, Twitter, LinkedIn, Google+ and Sina Weibo.

Looking back on the previous editions

Worldwide was born on 3 May 2016 when we launched the very first edition: the South Africa takeover.

The page aggregated content items to showcase Bath’s activities and impact in South Africa. The goal was to send clear messages about how our work in South Africa provided solutions to global environmental and social challenges, empowered future higher education leaders and developed top athletes of tomorrow.

Since this was the first time we have experimented to present the University's internationalisation on the website in this particular way, there was so much to learn throughout the entire production process, from content creation to curation.

Three months later, on 5 August when the Rio Olympics Opening Ceremony took place, we launched the second edition covering the Rio Olympics and Brazil takeover.

For this double-themed issue, we highlighted our Olympic hopefuls and demonstrated how the University was working with Brazilian partners to tackle environmental issues, understand the country's corporate governance reform, and strengthen links with industry.

This time, I worked with a wider range of sectors across the campus and produced a larger quantity of content. We also learned from the previous experience and iterated along the way to make the production process more efficient.

Adding a personal touch to the journey

Having been involved in every stage of the production process, I always feel bonded to Worldwide. Now I have to temporarily say goodbye to it as I'm expecting a new addition to my family.

There is no better way than to release a review version before I wrap it up and start my maternity leave.

A big thank you to all the colleagues I've worked with for making this happen. It's been such a pleasure.

I can't wait to deliver other exciting editions in the near future.


To infinity and beyond: my first 2 weeks in Digital

📥  Blogs, Team


As Christmas day fast approaches and the sound of tapping keyboards becomes a distant memory, I'm given time to reflect on my first few weeks in the digital team and what I've learnt so far.

About Me

My role within the Digital Marketing and Communications team is that of Content Producer. In time, I will be responsible for originating new content including audio, video and copy for the transitioned University website. I'm massively looking forward to this challenge and hoping I can use my creative eye, experience and vision to good effect. In the meantime, I have been somewhat haphazardly familiarising myself with the backend applications and processes that keep the digital team afloat. And which, quite frankly on the first day, gave me brain freeze!

I'm pleased to say this hasn't lasted.

What I've been up to?

There's no doubt there has been an awful lot to learn and mistakes have been rife. Justin and Rhian have been great and guided my early efforts with the patience of saints. This is all the more remarkable given the amount of work currently being shoehorned into place for Student Recruitment. So thank you and hats off! As with every well-oiled machine, it's important to be familiar with all the nuts and bolts that keep it ticking over and for the past couple of weeks I have been learning the basics: how best to use Trello, transitioning various content items on the Content Publisher, understanding the structure of Open CMS, learning about how the team functions, what Show & Tell is and how Standup works to name a few.

Am I the finished product? Not by a long shot, but Rome wasn't built in a day!

Who says all work and no play makes.....

In all honesty, I have been bowled over by the positive dynamic of the team as a whole. The agile method of working, something with which I was not all that familiar, actually works! Not only does it provide a great way to get to know the rest of the team but it encourages collaboration. The autonomy the agile method also provides really allows content producers to take full ownership of their deliverables whilst also advocating a 'two heads is better than one' approach. The functionality of the new CMS is clearly a testament to this. As is the laughter that sporadically echoes around the marketing floor!

What I've learnt?

What have I learnt in my first two weeks? Umm well, I've learnt I can eat Hanna under the table in an eating competition, that Richard has an incredible array of Christmas jumpers, and Phil (gone but not forgotten) has one of the most contagious laughs I've ever heard. However, I digress!

On a more serious note, I've learnt lots and am happy to have been thrown in at the deep end and given the freedom to make mistakes. After all, there is no better way to learn than by doing… then bogging it up… then doing it again… possibly bogging it up again and then finally getting it right! I feel fortunate that, in the heat of battle, frantically typing on my mac like something from the launch sequence of Apollo 13, I haven't got trigger happy and published anything I wasn't supposed to yet!

What do I like most about the department?

Attention To Detail - Everybody in the team is meticulous in their approach to content. Full-stop. No stone goes unturned and a real emphasis is placed on taking time to ask the right questions in order to develop 100% user-orientated content.

Passion - Everybody in the team is clearly passionate about their role and understands their contribution to the overall marketing strategy. This shared vision provides cohesion and direction.

Creativity - I really like the fact that the team's methodology is still a work in progress, people are open to challenges and finding new ways to improve their process. We are not afraid to tear up the rulebook or, of that truly terrifying word CHANGE!

Honesty - People can handle the truth here! I really like the fact that, because the culture is so positive, everybody is able to honestly analyse their own work and its value. In the best creative environments, there are no egos to tip-toe around, truth and logic can be handled and, as long as there's justification, challenges are welcomed and implemented.

The future....

What does future hold I hear you ask. Well, I'm looking forward to getting more familiar with the various faculty heads and processes, becoming a Jedi master of active corporate tone and, in time, helping to originate new content that meets the team's very high standards.

So thank you for having me, have a fantastic Christmas and, in the words of Tiny Tim,




The neverstarting story

📥  Beta, Communication, Development, Team

Do you ever have a piece of work that never quite makes it to the top of the to-do list? Something that needs doing but is not really crucial enough to be prioritised that highly. It lingers in the background, knocking on the door of your subconscious every time you think of the project.

We had something like that. A story in our backlog which so very nearly made it into sprints, but never actually did. This happened so many times over 5 months that it became known as the 'cursed' story.

Then one day it acquired a different nickname. The original product owner was so fed up of it not being done that he wrote this comment on it.

PO comment

And the 'champagne story' was born.

But the comment didn't seem to help because nearly a year passed before it finally made it into a sprint. The story itself seemed to become more daunting the longer it was unstarted. It was essentially about republishing related content when an item gets published. Important but not groundbreaking stuff.

In the end the story got reduced in scope and then finally made it into the backlog for a sprint. It just so happened that I was the person who picked up the story and actually got the feature done. After all the delays and near misses, the feature itself was quite straightforward to implement.

So you are probably thinking that there was much rejoicing at this being done and I went home happily clutching a newly acquired bottle of champagne? Well, not quite. You see, the product owner had since moved on from our team, so there was a question over whether the champagne would arrive. The team put out a few gentle reminders.


The message was out there and we waited. At the same time this was happening, it was my turn to bake for our GBBO sweepsbake. And that is when I had an idea.

What if I baked a cake in the shape of a champagne bottle to celebrate the story being done? And what if I delivered it anonymously to the office? I wondered what would happen.




It was a fun day. I sat back and watched as people in the office were trying to work out who had made this cake. There were some top detective skills put into practice but somehow I managed to get away with it until the following day when I owned up to being the secret baker.

All in all, I enjoyed finishing the story and baking an interesting cake for the team. I learnt a lot about my colleagues and how much fun they are to work with.

Keep shipping! (and baking)

One Hour Upgrade - December 2016 edition

📥  One Hour Upgrade

The inaugural monthly edition of One Hour Upgrade was a quieter affair than usual as the Digital team was ravaged with Christmas plague. Thankfully our numbers were bolstered by a couple of One Hour Upgrade neophytes eager to get involved.

Fewer participants meant fewer stories added to the backlog (11) and a higher than average occurrence of pairing on stories. In fact, there were no lone wolves in this upgrade.

As always, we started with a Thursday prep session where upgrade ideas are jotted on post-its and pinned to the wall for consideration by the wider team. On Friday, we took a few minutes to organise ourselves, pair up and decide on the tasks we wanted to take on.

What we got done

  • John, Rod and Phil added a touch of Yuletide glitz to the office, with a decoupage Christmas tree made from stationery, some Health and Safety-baiting boughs of holly and artisanal paper chains.
  • Miao designed beta badges for our new starters who had yet to receive them. As a result she was then officially sworn in as a licensed beta badge creator.
  • Justin and Rhian added much needed disabled access information from our main travel advice page.
  • Dan and Tegan improved our default link state colours, in particular by removing the inaccessible yellow 'focus' state.
  • Tom and Iris added ‘last edited’ information to the status bar in our Content Publisher app. This makes it a lot easier to see when a content item was last changed and by whom.

What we learned

  • Even a small team can ship real improvements in under an hour.
  • Holly fixed at eye-level to a doorframe with sticky tape is not a good idea.
  • If a One Hour Upgrade task needs further technical or design review, it *will* overrun into normal sprint time and should be captured as a new story in Pivotal.

What's next?

Our next One Hour Upgrade is scheduled for 13 January 2017.


And it's goodbye from him

📥  Communication

After more than a decade, tomorrow is my last day working in the Digital team.

The team's had different names, and I've had different roles, but my mission has always been the same: improve the University's online presence through applied use of technology. While trying to live up to this, I've been privileged to work not just with the developers, but also our editors, product support and designers.


With our recent work on the Content Publisher I'm happy that the platform and technology for doing that are now better than they've ever been. The team can now continue to build and innovate on top of a solid foundation to provide the University with the web publishing platform that it needs, evolving as user expectations increase over time.


Only a few years ago we had no dedicated support channels - instead we rotated the responsibility for looking after our users around the team. I can hardly remember those dark days any more - we've since introduced standards, reporting and guidance to be proud of. We've still got high ambitions in improving our service here, but with a user satisfaction rating of 96% it seems safe to say we're on the right path.


A much harder problem has been managing the content on For a long time there was no governance on how, why or when content was added to the site and so we've found find ourselves with a challenge.

The way we've approached this is to help each department change how it thinks about its web content, and where possible to be guided by our Delivery Principles.

This is no minor undertaking. Michael Slaby, Obama's 2008 chief technology officer, said it better than I could:

It's just change management. It's not complicated; it's just hard.

It's not only hard, but it needs to be continuous - large organisations have a tendency towards inertia that the internet and its users don't. The passion and energy of the people in Digital to take this on this challenge has been critical to our successes. It's something which I've also been amazed to watch them impart to others. The thousand new pages we've published in the last 12 months, and the thousand which are in various states of review and fact-checking right now wouldn't have been possible without the support and energy of all those departments we've been working with so far.


When most organisations come to revamp their website, the primary focus is on look and feel. What colours does it use? What's the logo? For us it's been something more, a complete change in how we think about the site. A break from organisation-out thinking to be user-in. Most people coming to don't know or care about which group is a sub department of which faculty, what they care about is being able to find the right information quickly, and being able to understand it easily. Our research so far has shown that our new templates, navigation and content guidance are doing this. They'll also continue to evolve as more departments come into Content Publisher and I look forward to watching the changes in the future.


We've had a number of people join the team in the last few weeks and I've been pleased to see them start to discover some of the things that kept me here so long - a variety of projects and products, an opportunity to expand your skills in many direction, a commitment to quality and an amazing team spirit.

I can only hope to find myself in another team with such a selection of hard-working, dedicated and passionate people in my next role. Thank you all.

The pursuit of Appyness

📥  Digital strategy

We love apps. Apps can provide interactivity and features that web pages simply can't. They can tap in to your phone's hardware to use the camera, connect to your address book to help you remember birthdays or send push notifications when important events occur.

A photo taken with Snapchat

Snapchat is a great example of an application which uses a phone's hardware. Photo by Ariel Chang.

But there are many things that web pages can do just as well as apps. They let you get updates on news and events, connect through social media or buy things online.

So, once every few months, when we are approached by someone with either an idea for a mobile app or a brochure from a vendor who promises the world, we ask a few questions.

  1. Does this information already exist on our web pages?
  2. If yes, then what extra benefit would an app bring? Who would maintain the two versions?
  3. If no, then does it exist anywhere else? How would making this into a University of Bath app improve it?

It often turns out that the information or functionality does already exist. Unless a new app is likely to provide a highly polished and professional interface (think about the Amazon, BBC News or Facebook apps) then we recommend that teams spend the equivalent time and money improving their existing web pages. This could be either by transitioning them to the Content Publisher to make them work better on mobile devices, or simply using usage data to improve the existing services they deliver.

Mind the gap

In the cases where we agree there's a space that a dedicated University of Bath mobile app might be able to fill, we ask three questions before beginning a trial:

  1. How can we tell how often it's being used and which features are popular?
  2. How does it look, feel and behave at the front and back-ends in real use?
  3. What are the security implications of this app?


Gathering usage data is critical, and yet many apps we've seen don't deal with it at all. We are committed to making decisions with data, and because we know that 77% of users never use an app again 72 hours after they installed it, we want to ensure there's a good return on investment.

Apps that are free to a user aren't free to the University. They have ongoing costs in terms of developer licenses, contracts, maintenance and brand association. This means that usage data (which is very easy to collect in mobile apps) is a requirement for being able to measure success.


We also always ask to use the app for a short while ourselves so we're not assessing a special demo version, or making a decision based solely on what it says in a brochure. This helps us to judge if the reality meets the promise. Is the content easy to update? Does the custom branding work well across multiple devices? Does the app work as expected?


If an app collects or uses user data we put it through a security check. If the source code is available, we will review it. The Security Manager in Computing Services will also take a look at any Data Protection statements and ask a provider to answer questions about data security and storage. It is not uncommon for apps to want to store personal data on servers in the United States, which breaks the University's eighth principle of Data Protection and means the provider will need to switch to a European data server.

In summary

Whilst we maybe have a more permissive view than the Government Digital Service, we always ask that University groups understand their users' needs and can ensure the quality, sustainability and security of an app before starting a trial.


Progressive enhancement and team memberships

📥  Beta, Development

We recently shipped some changes to how we order team members in our Team Profile content type.

These improvements came in several stages, each building on the last, so this seemed like a good opportunity to talk about progressive enhancement.

What is progressive enhancement?

The Government Digital Service's service manual has a great explanation of progressive enhancement:

It’s based on the idea that you should start by making your page work with just HTML, and consider everything else an extra.

This is because the only part of a page that you can rely on to work is the HTML. If the HTML fails there’s no web page, so you should consider the rest optional.

We prefer this approach to immediately building a feature with all the extras (like JavaScript) and then trying to make it degrade gracefully (or just keeping our fingers crossed that it doesn't break).

Progressive enhancement is important for accessibility. By making sure your feature works with HTML alone, you can be more confident that your feature will work for people who are:

  • using assistive technologies
  • on slow or compromised connections
  • don't have JavaScript enabled for some other reason

Progressive enhancement is also well-suited to Agile, as you can start with the core functionality and then iterate.

Introduction to the feature

Users have two options when it comes to creating team profiles:

  • 'Create manually' – create a list of names and roles using Markdown
  • 'Select from Person Profiles' – add Person Profiles to the team to pull through the member's name, role, photo and other important information

When we first built the 'Select from Person Profiles' feature, users had no say over the order in which the team's members were listed on the page.

Members with the 'Leadership Profile' subtype were always listed first. All other members were then listed in alphabetical order. Our users reported that this wasn't ideal and it was often important that members be listed in a certain order. For example, the manager of a team should probably be listed first, even if they don't have a 'Leadership Profile'.

Adding the order with HTML

Our earlier version of the Team Profiles interface did have some JavaScript. Adding the order was complex enough that it was easier to strip out any existing JavaScript and go back to basics.

After some complicated data structure changes behind the scenes, we had a shiny new field called 'Order in team'.

Team members in the base implementation

Team members in the base implementation

Users could now specify the order by entering numbers into these fields. When they saved or published the page, members would appear in the order they'd chosen, both in the interface and on the page itself.

Saving the page also added more empty member dropdown menus, so users could add more members if they wanted to.

We now had the core functionality, even if there was still room for a bit of polish.

We shipped this version of the feature and then moved on to the enhancements.

Adding the magic with JavaScript

We had the essential behaviour of the feature, but there was still room to improve the user experience.

Now that we had a feature which worked with HTML only, we could add enhancements for any users who also had JavaScript enabled.

Our JavaScript addition did several things:

  • replaced the multiple dropdown menus with a single one, which adds new members to a list below
  • allowed users to drag and drop the members in the list into their desired order
  • hid the member order fields, but updated them behind the scenes whenever users rearranged the members through drag-and-drop
  • added a remove button for each member to take them off the list

These enhancements make it quicker for users to add, reorder and remove team members.

Team members with JavaScript enabled

Team members with JavaScript enabled

If the user doesn't have JavaScript enabled, none of these enhancements kick in, but the feature still works as before.

This means the Content Publisher can still be used by broad range of people, no matter which technology they're using.

What comes next?

We don't work with JavaScript nearly as often as we do Ruby. As such, our practices need a bit of work.

Because the JavaScript implementation changes the interface, this means inserting HTML into the page. Currently we store this HTML in the script itself, which is messy and difficult to read. It's probably time for us to get familiar with a JavaScript templating engine – Handlebars.js seems like a likely candidate.

Trying (and failing) to test the drag-and-drop behaviour in Capybara also revealed that we need a better way to handle feature tests and JavaScript. We've got some planned investigation into Poltergeist which will hopefully sort this out.

While neither of these changes will be apparent to users, it should make our development process smoother as we roll these sorts of JavaScript enhancements out to other parts of the Content Publisher.


First impressions – five reasons why I love working in the Digital team

📥  Blogs, Team

They say a week is a long time in politics. But it seems just seven hours can be a political aeon. Because the day before I started my new role in the Digital team, I went to bed in a prospective mood, only to wake to the shock-and-awe news of Trump's election success. With two proud Americans on the team – and the rest of the department seemingly of sound-mind and warm blood – I walked in to an office that was in a palpable sense of shock. But that didn't stop the team welcoming me with open arms and big smiles. These guys are made of strong stuff, I thought.

What I'm doing here

My role here is that of Digital Producer. In time, I'll be planning and producing new content for the transitioned website. For now, I'm getting to grips with all the facets, faculties and faces of the University, and its marketing and web teams.

I come from the world of consumer journalism. Specifically, design and tech websites and magazines (which means I haven't tapped any phones; but I have reviewed a lot of them). In that life, I chased referral traffic and copy sales. If ever the mantra 'done is better than perfect' rings true, it's when you and a thousand other publications are wrestling for search dominance during an Apple unveiling. Fun? Sure. Rewarding? Regularly. Hectic? Definitely. Shambolic? Often. By comparison, the Digital team here is a well-oiled machine. Laser-focused, calm and professional. My new co-workers come from varying backgrounds, but what strikes me most is the air of expertise and attention in producing the best work possible, quickly, and with little-to-no fuss.

The story so far

In my first two weeks, I've sat in on planning meetings; taken part in sprints and fast-turnaround tasks. I've watched as seemingly impossible requests are explored, executed and delivered within what should be unscalable deadlines. I've been to two Show & Tell events – single hour sessions every second Friday, where the team and invitees present success stories and share knowledge – and been blown away by the confidence of the presenters and the quality of the work. And above everything – I've not heard a cross word exchanged.

Plenty of opinion, yes. Healthy debate and cross-examination, sure. But all for the greater good of the task in hand.

This isn't just refreshing. It's positively energising, and a world away from the frazzled grind of consumer journalism.

Why things are GOOD

In keeping with my previous career, though, I thought it might be appropriate to get the last of the clickbait out of my system with a time-honoured listicle.

Behold my five favourite things about working in the Digital team, and what I've learned in the last three weeks.

  1. People care. They care about the quality of the work. They care about how it's presented. They care what it says about the Digital team and the University.
  2. Reason underpins everything. There's no punts; no execution without validation. Hunches are locked in a top drawer. It's not empiricism, it's user-centric design at its finest. And it works.
  3. Office furniture is for sitting on, not for hurling at staff writers. Critical interrogation is welcomed here. Without having to duck from an airborne keyboard as you spike someone's copy or question their caption writing.
  4. I’m surrounded by really smart people, both the academics and University staff; and the direct team I work with of developers, editors and designers.
  5. There's a clear goal, and it's not improving a bottom line or turbocharging share value. It's in producing the best quality work possible within a deadline that does the job it was designed to do.

Have I landed on my feet here, I asked at the end of my first week. Yes. Definitely. A week might be a long time in politics – but in the Digital team, time's flying and I'm having fun.


Are we there yet? 3 years in agile design

📥  Design

It’s been almost 3 years since I joined the University of Bath digital team and, despite committing wholly to the agile workflow, I’m still struggling to reconcile certain aspects of our working practice with the freelance life I left behind.

As a designer with almost 20 years of experience and weened on a thoroughly waterfall design process the thought of handing over ‘unfinished’ work to a stakeholder is still an uncomfortable one.

How good were The Good Old Days?

In ‘The Good Old Days’ done meant done.

As an interactive designer I’d often be tasked with producing dozens of pixel-perfect page designs illustrating every conceivable content type, state and variant. These layouts were honed, polished, considered works-of-art (at least in my mind).

And these designs were considered final. The end of the design process. I was done. These static snapshots of a site were then presented to project stakeholders as a fait accompli.

“Do you like the design? This is what your site will look like”
“Yes. It looks great.”
“Wonderful. Summon the developers - we have a site to build!”

The Minimum Viable Product

In the Digital team, we use agile methodologies when designing and developing. In basic terms, this means that we are constantly iterating, improving and updating small, discreet elements of our designs based on feedback.

The upshot of this is that the first version, the thing you launch, the live site, is not perfect. In fact it never will be.

The MVP (Minimum Viable Product) is a base-level, functional version that lets the user do what they need to complete a task or locate a piece of information. For a designer, used to polishing a design within an inch of its life before letting anyone see it, the MVP is a rude awakening.

Things aren't perfect, they aren't the best they could be. They most certainly aren't finished. However they do meet the users needs for a functional, viable experience.

The lack of control still makes me feel nervous but designing for a specific user need has changed the way I think about my work.

Just ship it…

It can sometimes seem like an agile project has no plan, no overall vision for the end result.

From a design perspective, this can be frustrating when working on the conceptual elements of a design. Trying to get a grip on what *everything* looks like and how it holds together can be tricky when working on a single aspect of an interface component or tiny piece of functionality in seeming isolation.

The understanding of when an MVP can be described as viable is a skill in itself. The PO (Product owner) holds the product vision and is the arbiter of 'ready' - they say if a component, a template or a feature is in a position to ship.

And shipping happens as often as possible. One of the basic tenets of agile is that we look to get things in front of real users as quickly as possible. Any feedback the users provide is then used to refine or create further user stories to iterate on the previous work and make it better.

I may not have my pixel perfection but I do have real, genuine data from those on the coal-face using the things I have designed.

Caring (for your users) is sharing (with your users)

Putting things in front of people is still scary after all this time. No-one likes criticism. We certainly don’t like watching anything we have worked hard on fail.

The flip-side of this is that user-testing is a liberating, eye-opening experience for any designer. Watching a user struggle to find your meticulously crafted call-to-action or swiftly complete a complex multi-stage task brings you closer to your users.

I love this new-found connection with the end users of the products and services I design.

The MVP of embracing agile…

… is an awkward hug with good intentions.

Learning to embrace agile has certainly been a challenge. Three years in and my user stories could always be better, my fear of bad feedback has only slightly diminished and my frustrations at shipping something that (I think) looks like a dog has chewed it a bit have not abated.

However, the openness of communication and the interaction with the people who use the things I make on a day-to-day basis have meant that I believe my design skills have improved immeasurably.

Maybe it is possible to teach an old dog new tricks.