Springer Nature

Springer Nature logo

Growing and supporting the User Experience Department

  • Client
  • Objective
    • Supporting the Global Head of UX to provide ways to support and grow the burgeoning User Experience Design department within Springer Nature
  • Work type
    • UX, Management, local, international
  • Timeline
    • October 2016 to October 2018
  • Team
    • Global Head of UX (London)
    • Team of 5-6 UX Leads (including myself, London)


Having previously worked as a Senior UX Designer for Springer on their Springer Materials and Nature Nano products, I was asked in October 2018 to become a Lead User Experience Designer, in order to help assist the Global Head of UX in expanding the User Experience Design department. Following a merger with Nature, another leader in the scientific publishing field, the demand for User Experience Design support had grown, and we therefore had to grow the department in order to meet this need.

Given my previous experience in working with international teams based in our Pune office (previously part of Crest Premdia Services), I was asked to build and develop a team of User Experience Designers, to work onsite with software development teams in that office, ensuring that user experience design was a key part in the production process.

The Springer Nature Pune office at sunset

The Springer Nature/Crest office in Pune

Building the Pune UXD department

Part one

In order to ensure the success of the new Pune UX team, I took a three-stage approach to the issue:

  1. Developing the recruitment process
  2. Increasing awareness of User Experience Design within the office
  3. Supporting the team

Developing the recruitment process

To start, we needed to ensure that we recruited the right people for the team. I developed a recruitment process that would help with this, which incorporated principles including Lou Adler’s Performance Based Hiring, which helped us write job specifications that focussed on role expectations, rather than a laundry list of requirements. By doing it this way, we could ensure that potential recruits would not be put off by a list of things they could not do, and we could focus more upon the actual tasks they were expected to complete in their project. This approach has been adopted for the whole of the Global User Experience Design department, and is now being adopted by other discipline roles, such as development, project management and business analysis.

This approach did receive some pushback from the HR Department in Pune, as, despite my explanation into how the technique worked, they found it harder to evaluate potential applicants, as they did not have a list of key terms to look for in submitted CVs. I therefore worked with the team, to evaluate the process further and ensure that a light touch evaluation could be carried out by the HR team, to extract people who were very clearly not suitable, but the main evaluation would be conducted by myself and other UX Leads, to ensure that candidates had the right skills, or showed promise in being able to achieve them.

Sticky notes showing how we planned the recruitment process for the Pune UXD team

Planning the recruitment process for the Pune UXD team

A diagram showing the devised process for recruiting User Experience Designers in Pune

Sketching our planning into a scheme for evaluating candidates

Alongside my fellow UXD Leads, I helped design a process to help evaluate candidates that would not only work for my recruitment purposes in Pune, but also normalised the process across each of our offices, to ensure that candidates from each country would be evaluated equally, and therefore maintain levels of expertise across the company.

  1. CV review – CV is reviewed by Pune HR, and a member of the UX team, to make sure they show possible suitability for the role.
  2. Pass/fail evaluation – if suitable, a screener call is arranged
  3. Screener interview – candidates are called via video conferencing or phone, and asked questions to ensure that they can answer basic questions around their application and history, helping to quickly ensure they are knowledgable about UX and their work history
  4. Pass/fail evaluation – if they are successful, we can then invite them in for an interview.
  5. Interview day – As candidates often had to come in from far away, and to speed up the process, we would then hold interview days for several candidates, consisting of:
    1. First interview – an interview with one of the UX team, as well as members of their prospective production teams, to further investigate their work history and suitabilities for the role.
    2. Practical test – candidates were then given an hour to work on a UX solution for an open-ended problem on their own. This would give us the ability to not only see how the candidate worked under pressure, but would also allow us to stagger the interviews. The candidate would then be asked to present back their work, so we could evaluate how they approached the problem.
    3. Pass/fail evaluation – if the team in Pune is happy with the outcome, then one final stage is arranged:
  6. Video call with UX Lead/Global Head of UX – for the times when I was not present in the Pune office, I held a video call interview with the candidate for one final stage, to get an idea myself of their abilities, and ensure a good cultural fit with the company.

I started the process myself, conducting interviews from the Pune office, and, when we had recruited a few people for the team, I asked them to carry on the process while I monitored it from the London office. This process helped us ensure that candidates were suitably able in their roles, as well as providing a rapid way of evaluating them, as it was common for Indian candidates to be lost to offers from other companies, making the speed of evaluation and offer key to securing decent people for the team. I am proud to say that, from this process, we hired a team of very capable User Experience Designers who helped us to expand the influence of our department to the production teams over in Pune, and worked well with their UXD colleagues in our London, Berlin and New York offices.

Increasing awareness of User Experience Design within the office

While I was over in the Pune office conducting interviews, I also spoke in depth to the teams who we were hiring designers for, and found that the understanding around the role of User Experience Design to be rather confused. Many members of the teams had not worked with User Experience Designers before, and so I put together a presentation to help explain some of the principles behind User Experience Design to help them:

Slide from the what is UX presentation
Slide from the what is UX presentation

Slides from the “What is UX?” presentation I gave to help explain UX principles to production teams in Pune.

Supporting the UX team

Alongside this presentation, and having hired the UX Designers for each team, I set up a number of regular contact points with key individuals, to get a good picture of how things were going with each designer and their project:

  • A weekly call with each designer – this would ensure a regular touchpoint where I could discuss with each designer their work, how they felt it was going, and ensure that they had the resources and support they required. We also discussed how they felt things were going, to get a view of satisfaction in their role, as well as sharing intelligence about other relevant goings-on in the company.
  • A weekly call with the heads of projects – this helped me to understand the business requirements for each of the teams that my Pune team worked with. It also helped me formulate strategic decisions for ensuring that sufficient UX support was given to each project.
  • Regular catchups with the project managers – this gave me insights into how each team was performing as a whole, and ensure alignment of expectations from both my designers and their teams.

This approach helped me to identify problems and issues in good time, which helped me give an overview of how things were going in Pune, to the Global Head of UX and my fellow UX Leads in London. We could then decide if changes needed to be made, such as moving designers between teams, or recruiting further support.

When visiting the Pune office, I would frequently hold group sessions with my team, to examine issues together. In these sessions, we would write down issues which were helping and hindering us from our work:

Sticky notes on a board, outlining the outcomes of a session discussing the problems we face

Outcomes from a group session, examining the successes and problems we have faced (please note – this image has been pixellated to protect anonymity)

This workshop approach helped us share good and bad things about our work, and form ways of approaching common issues. I frequently encouraged team members to answer each other’s problems, so that they could assist each other at the times when I was not in the Pune office.

Building my coaching skills

Part two

During my time working with the Pune UXD Team, I also attended workshops on coaching, mentoring and leadership:

A photo of the notes I took during a coaching workshop

Notes I took from a coaching workshop

These workshops helped me to further understand ways of enhancing my team’s performance, as well as ensuring that their work was in-line with the Global UX plan.

Enhancing the skillset of the whole UXD department

Part three

Evaluating and enhancing with skills maps

As part of an exercise to assess and improve the skill levels of the entire UXD department, based across our London, Berlin, Pune and New York office, my fellow UXD Leads and I embarked on a project to conduct examinations with each member of our teams, to build a picture of where strengths and deficiencies lay with each person. We built a Skills Map, a multi-page spreadsheet that would allow us to go through each key skill with our team members, understanding how confident and capable they felt about each.

Screenshot showing the spreadsheet and analytics we used to measure skills levels across the UX team

Screenshot of the skills map spreadsheet, showing how we measured team members on various skills, and provided analytics to get an overall view across the department

We combined the findings to build a picture of the areas we needed to focus on. The areas of interest would then be either set out for team members to focus on individually, with us helping them by providing opportunities to read or practice a certain area of interest, or, if we felt that they were an area of interest across the department, we would conduct department-wide training, such as holding lectures or conducting discussions, to facilitate learning on a particular subject over a larger group of individuals.

Developing a UX playbook

We also went through Jared Spool’s UXD Strategy Playbook to ensure that we, as a department and a company, were headed in the right direction. We examined each of the plays, assessing where our individual teams were in each, and then combined the findings to give a picture of the whole UXD department, and, ultimately, the company’s current state of UX involvement.

A glass wall with pieces of paper showing the outcomes of our UXD plays

The outcome of our UXD plays exercise – please note, this image has been pixellated for confidentiality reasons

This helped us to define our own UXD playbook, and know where we, as a department, could help steer our team members, ourselves, and, ultimately, our company in ensuring full immersion into a way of operating that put the user at the centre of everything we do.


I learned a lot as a UX Lead for Springer Nature, and it certainly provided me with plenty of resources and skills to contribute for future positions. One thing I did find was that I missed being involved in the actual “hands on” work of User Experience Design, and that I preferred being involved in the strategic thinking behind products, rather than working with just developing and supporting designers. That said, I did receive some good feedback from my team about the levels of support I provided, with one even calling me “the best supervisor they have ever had”, which was very pleasant praise to receive.

For more information, or to discuss this further, why not get in touch?

Similar projects

  • Logo for Nature Nano
  • Springer Materials logo
  • Logo for Springer Healthcare

User Experience Design, a personal perspective

User Experience Design, or UXD for short, is described in its Wikipedia entry as “the process of enhancing user satisfaction with a product by improving the usability, accessibility, and pleasure provided in the interaction with the product”. Whilst this is a sufficient summary to explain UXD in a brief way, I wanted to take the chance to explain more about User Experience Design, how I view it, how it works for me, and what how I feel it can be beneficial, not just to me, but for companies that put the user at the centre of what they do.
Continue reading

More about me…

Andrew Robert Burgess


Part one

My name is Andrew Robert Burgess, or Andy for short. I’m a User Experience Lead, having worked previously as a Graphic and Digital Designer, and a Front End Developer since I started my career in 1999. This has helped me get a really good understanding of not just the processes which go towards creating a great user experience for the product or service on which I am working, but also experience and knowledge of how best to work with production teams, and knowing what is required to fully optimise that product or service to give the best message and representation.
Continue reading

Nature Nano

Logo for Nature Nano

Helping to build and improve a new database solution

  • Client
  • Objective
    • Helping to build and develop Nature Nano, a database of information on nanomaterials for scientists
  • Work type
    • UX Design, Databases, international teams
  • Timeline
    • Sep 2015 – Feb 2016, Oct 2017 – Oct 2018
  • Team
    • Lead UX Design (me, London)
    • Technical Product Manager (Heidelberg, Germany)
    • 2 x Business Analysts, Project Manager and team of 6 Developers (Pune, India)


Nature Nano is a scientific database, much like Springer Materials, but providing information, articles and patents related to the nanomaterials and nanotechnology disciplines. Branded under the Nature side of Springer Nature, it attracts a more corporate audience that Springer Materials’ academic one.

I was brought in at the birth of the product, when the team needed help in working out how the product would function, and then later when they needed help in producing an additional database of patents. I helped the team to research and understand their audience in both cases, and build solutions that suited the needs of their users.

Creating a nanomaterial database

Stage one

I was originally asked to join the Nano team when the product was first being considered. Springer Nature had a series of sources of nanomaterial data, but needed help and guidance on who would make use of the data, and what they required from it. My job was to conduct research to understand those needs, and to help the team to understand it while planning how to build the product.


Having previously worked with Springer Materials, I used my experience in researching user requirements for database products with this project too, and employed the same principle as I had previously – understanding not only how people look for and use data, but what they do before and after that, to understand the context around how the action fits into their everyday work

The process I took from my experience with Springer Materials, understanding what happens before and after the user comes to the database

The process I took from my experience with Springer Materials, understanding what happens before and after the user comes to the database

We were provided a series of users, some provided to us by the Product Owners, as well as recruiting them online and finding them amongst out own community of scientist contributors that write for the academic journals that Springer Nature publishes. In the interviews, we asked them a range of questions, including:

  • Describe to us what you do in your everyday work? – this helps us to get an overall picture of the user’s work and environment, as well as possibly identify opportunities to use the product which we had not identified before.
  • How do you use nanomaterials data in your work? – this focusses on where the data is used, and helps us to explore what they need to use the data for
  • What do you do with the data when you have it? – here we explore the best way to provide the data, and whether we need to facilitate using the data for other purposes, such as transferring it to another form of storage, taking it away to work with somewhere else, or inputting it into another facility to manipulate and work with.
  • What are the challenges you face in your work? – asking this allows us to understand opportunities where we might be able to make their process easier, and help the user with our product.


Some of the things we found included:

  • Users don’t have time to read everything – a common problem in the scientific community, data is provided in academic papers and journals, making it very hard to locate without having to digest the entirety of the paper (I refer to this problem as “drinking from the fire hose”).
  • Information needs to be reliable – there are many sources of data out there, some of which are questionable. Users need to be confident that the information that they are using is trustworthy. This also has a cost impact, as libraries cannot afford to provide all information sources to users, so they need to be sure that the resources that they are using are reliable and suitable for their users.
  • Data needs to be portable – users want to be able to take the data away with them and work with it, and would appreciate a way of being able to check information quickly and easily.

Sharing and embedding findings

In order to share this information with the production team and stakeholders, I created a number of personas, based upon the information I had found during the user research, which helped define the different types of user, and their requirements for the product. As well as having direct users, I also included a persona for a “buyer”, a user type that is responsible for purchasing the product for their institution, but not using it every day, as their needs were also important to consider when creating the product.

Persona layouts devised for Nature Nano showing different users and their requirements

Personas devised for the start of the Nature Nano project

These personas were not only created, but kept up to date as more information as gained during rounds of user research and testing (see my introduction to user experience and testing to explain how regular user testing helps to ensure that a product is on-track with user requirements).

I also shared insights into the research by providing quotes from users, which further informed the team about what users wanted from the product:

“Your product should not shy away from being an educational tool, showing details of how to use the information on the screen, and what it means. This would open the product up to young researchers and other customers.”
English student researcher

Turning findings into a plan

We then held a week-long inception meeting in our office in Pune, India to discuss and plan how to build the product, including the production team and stakeholders for the project. I started by giving a presentation of all of my research findings, including the personas and quotes, and then involved the team by getting them to explore the information that I had given them in a series of workshops, devising ways to address the needs of the users in the final product. Breaking up into groups, the team wrote out user goals, and then began to build user journeys to explore how they could approach those problems. We then asked them to present their solutions back to the other teams, so that they could be understood, challenged and discussed.

A member of our Pune production team, wiriting out user goals from the personas

Writing out user goals from personas

A member of our Pune production team, explaining how a user progresses through the proposed product

Explaining a proposed user journey

This not only ensured that the team had the needs of the user in their minds, but also that the user needs remained at the centre of the project throughout. From this, we began to build a picture of how the product could work:

Glass wall with a large number of sticky notes, explaining our thinking around how we were going to build Nature Nano

Planning the way that Nature Nano would work

Building a prototype

This was then made into a working prototype, starting with a very simple version, using static HTML pages as examples, so that we could then test and explore the concept with users.

Example page on Nature Nano, showing the amount of details provided for gold nanoparticles

Example page on Nature Nano, showing the amount of details provided for gold nanoparticles. See the page live here.


The resulting product, which launched in late 2015, incorporated the following attributes:

  • Being one of the first resources in the filed of nanomaterials to provide in-depth information from a range of reliable, peer reviewed sources, giving users a “one-stop” source to find data
  • Providing links back to the original articles, so that users can check provenance, as well as keep up to date on the latest developments in a certain area
  • Allowing users to save, extract and manipulate the data they find, to use it in their own experiments
  • Working on a range of devices and resources, allowing any user with access to check details quickly and easily

“Nano is one of the best products out there. My researchers are very glad I bought it for our university.”
American university librarian

Adding a patents database

Stage two

Having worked on other products for some time, I was brought back onto the project in October 2017, to assist with adding a new and significant dataset to the product – the ability to research patents related to the nanomaterials that were already there. The team had already started by building a prototype, allowing me to explore the data with users, and get their feedback.

User testing the prototype

Before starting user testing, I explored the product myself, and built a rough idea of some of the main tasks carried out, as well as some of the questions I would ask the users.

Sticky notes showing my exploration of the patents section, defining the questions I was going to ask during the testing

Sticky notes showing my exploration of the patents section, defining the questions I was going to ask during the testing

I then organised the testing sessions, and, in order to involve the team even more closely with the research, I asked them and stakeholders to take part in the video calls by making notes of the session. I was the only one allowed to talk to the users, asking the team to mute their microphone in order to avoid confusion in the session, but allowing the team to communicate with me over a Slack text conversation, so that I could ask questions and raise points on their behalf.

Photo showing the dual screen setup I had for user testing - speaking to the user on one screen, while getting feedback on the other, and my notes printed out in front of me

Testing on two screens – video calling the user on the left, and speaking on Slack to colleagues on the right, with printed notes in front of me. (image has been pixellated for confidentiality reasons)


These sessions were not only user testing, but also a chance to ask and find out about the users and their needs for the product. Some of the discoveries we made were:

  • Patents are widely available, but poorly curated – products such as Google Patents already provide the ability to find patents online, but being able to locate the correct information can be difficult
  • Users want to be sure that they have all the information – users often seek out patent information in order to identify opportunities, possible areas where they can benefit from creating new patents. They therefore need to know that they have all the patent information to hand, as finding new information later could cause difficulty.
  • Users want to be able to see trends – as well as seeing the patent information, they want to see trends of interest, how many patents have been taken out on a given subject, again to identify opportunties

“You’re not going to beat Google by speed, so you need to show what makes you different from them, and what you offer adds value.”
Canadian scientific researcher and user testing participant

Sharing findings with stakeholders

I also communicated these findings in a series of presentations for stakeholders, outlining feedback from the users, and helping the stakeholders make decisions about how to improve the product.

An example slide from my presentation to stakeholders

An example slide from my presentation to stakeholders, showing them feedback from users (image is pixellated for confidentiality reasons)


Using, these findings, we were able to build iteratively on the prototype, and incorporate the following features:

The patents prototype has now been added to the main site, and is working as a beta. It has already gained interest from various corporate institutions, indicating that the customer base may well grow because of our efforts.

For more information about this project, or to discuss this further, why not get in touch?

Similar projects

  • Springer Nature logo
  • Springer Materials logo
  • Logo for Springer Healthcare

Springer Materials

Springer Materials logo

Designing databases for academic and corporate science

  • Client
  • Objective
    • Improving upon an already existing flagship database product, increasing subscriptions from customers by enhancing the existing offering and improving the user experience.
  • Work type
    • Databases, UX Research and Design, International
  • Timeline
    • Continuous, over a period of two years
  • Team
    • Senior UX Designer (me, London)
    • Junior UX Designer (Pune, India)
    • Technical Product Owner and Business Product Owner (Heidelberg, Germany)
    • Business Analyst, Project Manager and 
 6-8 Developers (Pune, India)


Springer Materials is a subscription-based online database, providing information for chemists, engineers and other scientists on the physical properties of elements and compounds. As Senior UX Designer on the project, it was my responsibility to develop the site to improve engagement, reduce attrition, and develop value for customers. In order to achieve this, I engaged a programme of work that would help address these issues.

Research and Analysis

Part one

To start, I conducted analysis of the current information architecture of the site. I started by conducting user research and testing sessions, which included the following explorations:

  • How do you use Springer Materials in your everyday work? – this helps me understand how Springer Materials fits into their working life, as well as giving me wider context around the requirements and decisions that cause them to need to use the site.
  • What kind of information do you look for? – the breadth of data on the site is quite wide, and used by scientists across a range of disciplines. This helped me to define what information was more popular on the site.
  • Can you show me how you get to this information? – switching over to a little more of a user testing scenario, I would get users to show me how they would find information, and observe the number of steps and ease with which they found what they were looking for.
My exploration of the User Interaction process, following my user research, including what the user did before and after coming to Springer Materials

My exploration of the User Interaction process, following my user research, including what the user did before and after coming to Springer Materials

Following these research sessions, I identified some of the more popular data sources on the site, and drew diagrams to explain how they were currently located on the site:

Analysis of the user journey to find benzene in Springer Materials

Analysis of the original user journey taken to find the boiling point of benzene

As the example above shows, users have to take a large number of steps to locate a simple piece of data. This was an example of classic “experience rot” – continued added functionality without overall scope degrading the overall user experience. One key reason for this was due to the fact that Springer Materials was originally created from the Landolt-Börnstein series of data books, which had been scanned to PDF, and broken up into relevant sections, resulting in users having to download the relevant section, and then go through the PDF to find the datapoints they required. Along with the series of unnecessary steps to locate the PDF in the first place, this was a distinct problem for users, as they came to Springer Materials to find information quickly in the first place.


Part Two

From the research, I had understood that users had trouble locating information on the site, which caused frustration, abandoned user journeys, and had an impact upon sales of subscription renewals to the product. It was clear that we needed to reduce the number of steps taken to find information. The way that we did this was through improving the search on the site, which would allow people to get to the data they needed more quickly.

Improving the search – bringing context to results

In order for the site to answer user queries more quickly, we needed to provide better context for the search terms. Our previous search method used a text-based search, similar to that found in many library systems, where it took the inputted terms, and searched for incidences of those words in the text it held. A user looking for “tin” would get results for “tin” (the simple metallic element), but then also get results for “TiN” (Titanium nitride, a ceramic compound). We clearly needed to provide better context for these searches, in order to reduce unwanted search results.

Sketch planning, exploring ways that we could improve the context of the search results

Sketches to explore ways in which we could introduce context and more advanced ways of searching into the product (note – not all of these were used)

We collected our ideas together, and elected to improve the search in two ways: first by introducing a suggestions drop down below the search input, allowing the user to specify what they mean by what they are typing in. The second part involved bringing in a graph-based search system. This meant that if the user selected something from the suggestion drop-down, it also incorporated a knowledge base that provided more context about that subject. For example, instead of seeing “tin” as merely a combination of the letters t, i and n, the system sees “tin” as the metallic element, with the chemical symbol “Sn”, the atomic number 50, and other details, which helps provide more relevant details. You can see evidence of this on the live site – a search for “tin” on the ‘focused’ search (which is what we called it to avoid technical confusion) gets 263 results, whereas searching using the old style text search provides 3653 results.

“This is great. It really will save me a lot of time searching in the future.”
Corporate researcher at MRS Boston 2016

Improving user pathways – reducing steps

Not only did changing the search help reduce the number of reduce the number of steps the user took to get to information, but we also used the studies I had previously done to analyse where we could improve some of the paths taken after searching to reduce those number of steps there, too. I provided a series of proposals of which paths could be reduced, and provided them to the team to implement:

Proposed user journey to improve finding the boiling point of benzene

Proposed user journey to improve finding the boiling point of benzene (compare with the previous version above to see the difference)

While some of these proposals were acted upon, some of the paths in Springer Materials have yet to be amended, as they became quite a long and involved task. However, we managed to improve the key “red routes”, or most popular user journeys, which reflected well when tested with users.

Digitising data

One of the key parts of the plan was to try and bring the data from out of the PDFs, into a digitised format that could be easily manipulated and experimented on by the user. This proved a difficult task, as it was not merely a case of copying the data from the PDFs onto the site, but also having to curate the data, in order to ensure that it was organised in such a way that allowed it to be found easily. Getting stakeholders to buy into this idea took time and persuasion, but I ended up getting them to hire the services of allied post-doctorate teams based in Germany and the USA, who assisted us with the curation, and made the data ready for us to use.

We combined the new data with producing a new set of pages to display the data on, which we referred to as the Landolt-Börnstein Digital, or Springer Materials Interactive pages. These pages would not only display the desired datasets, but also provide the user with interactive visual elements, which showed the spread of the data, and allowed the user to select a slice of the information, before having it represented in tabular format.

Sketch showing concepts of how the overall user journey could work, including ideas for improved search snippets

Sketch showing concepts of how the overall user journey could work, including ideas for improved search snippets

I also encouraged the team to look at the whole user journey, providing suggestions on how the search snippets could help to show basic information before getting to the whole dataset. This, sadly, wasn’t acted upon, due to resource restrictions, and we focussed just upon producing the actual interactive page. However, going through several different iterations, which were tested at each stage, and met with some very positive responses.

Sketch planning page layout for the digitised version of Landolt-Bornstein pages in Springer Materials

Sketch for digitised data page

Screenshot of the digitised LB page

The finished digitised data page

“This is awesome. I don’t think anyone else is doing this. Where do I sign up to get this for my university?”
Student researcher at ACS 2016

Issue: finding users to research with

Part Three

One of the major problems I found with trying to conduct user research on this project was the was in which I wasn’t in easy contact with the users. On other projects I had worked on, Project Owners and stakeholders would often be in contact with the users, as those owners were often both the people who used the product, and the people who purchased access to it. However, in this case, there was a more complicated set-up involved.

A diagram showing the complication of the relations between the users at a university and the production team at Springer Nature

A diagram showing the relation between my production team, the users, and the various steps in between.

Due to this rather protracted relationship between the production team and the customer institution and its users, I was not provided with users with which to conduct research and testing sessions with. However, I used the following methods to locate the much-needed users to work with:

  • Online recruitment – researching customer institutions online, on sites such as LinkedIn, Science Direct and others, I would collect lists of possible candidates. I then would cold-approach them, which had a relatively low success rate
  • Recruitment drives – I would send notices round to customer institutions asking for volunteers. This also didn’t yield high numbers of recruits, but helped to complement the ones I had already attained
  • Website advertising – using banners on the site, I would appeal to users to take part in research and testing. This had some degree of success
  • Guerilla testing at conferences – I attended conferences where we had a sales presences, such as the ACS and MRS conferences. I would then approach people who came to the stall. This was a fairly successful way of getting quick 15 minute sessions of user feedback and testing, but the people I talked to weren’t always active users of the product.
Conducting user testing at the ACS 2017 conference

My colleague, Aratrika, conducting user testing at the ACS 2017 conference

For more information, you can read the blog post I made about these methods, and how others can use them for their research. This did provide sufficient numbers of users for getting feedback for the work we were doing, but I did have to continually justify the low numbers of results to Project Management, who would have, on other projects, been responsible for providing those very users. My persistence paid off, as the results showed that my work was having an effect.


Part Four

As mentioned before, we received some good feedback from our improvements, when testing them individually with users. We also managed the following gains:

  • The introduction of the Interactive pages brought it to the level of a “best in class” in its field, winning accolades from professional bodies.
  • In 2017, the Indian Government bought licences to provide Springer Materials in all libraries across the country, which greatly widened the subscriptions and exposure of the product.
  • A site survey, run towards the end of my tenure on the product, showed that 69.2% of users classified the product as “great” (in a selection between “great”, “okay” and “bad”), an improvement of 22% from a site survey run towards the start of my time on the project

I felt I definitely contributed well to the original remit of improving engagement, reducing subscriber attrition numbers and developing value for the users. The examples above show only the more significant parts of the two years I spent on the project, and don’t necessarily account for the issues faced with pushback from business interests, problems with user recruitment, and other hurdles I faced during the project. However, despite this, I can happily say that my work has had a lasting effect on the product, and has taught me a lot about getting results in less than perfect circumstances.

Similar projects

  • Springer Nature logo
  • Logo for Nature Nano
  • Logo for Springer Healthcare

Designing notifications, or how we could learn to love our phones again

Another day, another article providing a soul-searching insight into why quitting smartphones is the new quitting smoking. These articles seem to occur regularly in the media these days, with accounts of people who feel trapped by their overuse of their phones, how they feel that their digital life is impinging on their real life, with their phones turning into monsters that continually buzz at them with notifications. These articles end up preaching solutions such as digital detoxes, phone stacking in restaurants, and have quotes from people saying how much better they feel when they don’t have their phones switched on, or even with them.

For me, the problem doesn’t lie with the way we interact with our phones, it’s about how our phones interact with us. When the web giants such as a Facebook, Google and Amazon began to realise just how much money could be made by advertising, they not only cashed in, but began to manipulate their properties so that they could multiply their efforts. The way that this was achieved was by factoring in design and functionality that encouraged compulsive behaviour. You may have heard of the “slot machine” effect of the Facebook newsfeed, encouraging you to pull down and refresh to refresh your newsfeed and get that dopamine hit of new content, or feedback on your contributions (in the interests of fairness, this isn’t actually exclusive to Facebook, many other apps have the same action, with similar effects). Many sites and apps use patterns to encourage further participation, and to keep the user on their product, and, whether intentionally malicious or not, some of these can evolve into dark patterns.

One such dark pattern that’s prevalent on almost every mobile device I know of are notifications. Even if, like me, you’re very stringent on keeping notifications on your phone to a minimum, whenever you download a new app the assumption is that the app can, unless you tell it otherwise, make noises, put messages on your lock screen and show banners whenever it wants to. In order to curtail this, you have to go into your settings and specify what notifications you receive. Apple and Google have made this easier to access in recent years, but it’s still an opt-out process, rather than an opt-in one, and for good reason – app makers want your attention on their products, and so want this way of bombarding you with information regularly, in the hope that you will give in, click on the link, and buy the product. Chances are, you’re probably not quite as hardcore with your notifications, so just imagine how fewer ones you would receive if you could choose to opt-in, rather than have to make the effort to opt-out?

Chances are, companies such as Facebook and Google aren’t going to go away, and they will certainly be around longer than the time you decide to go on your digital detox and later decide to rejoin the connected world, and, what’s more, you can be pretty sure that a lot of your friends are still going to be using them. However, there is a rising tide of interest in how these companies conduct themselves; we’ve seen questions into fake news, how they structure content on your timeline, and whether they should be responsible for the media that appears on their platforms. In my view, we should be asking these companies to not only look at the content they provide, but also the way they provide it. They should work out what their relationship with their users are, and how that they can provide advertising and updates in a more conscientious way. These companies aren’t the only problem, but if we could get them to change and show the benefits of doing so, others may follow suit. Through better notification design, we could learn to love our phones once again.

Designing for stressful situations

On Saturday 13th January 2018, residents of the US State of Hawaii received an alert on their phones. Instead of a text from their relatives, or the latest football scores, the alert gave the ominous message of “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL”. In an environment of the realistic threat of nuclear war indicated by the US President’s tweets, alongside the continual goading and threats put out by North Korea on their state television networks, the announcement was met with derision, confusion, and overall, undue widespread panic. It turned out later, following a second message indicating that the first one was a “false alarm”, caused by an employee during a shift change at the Hawaii Emergency Management Agency, who intended to send out a “test” message, instead of a “live” one. This resulted in a public apology from the Governor of the state, and much embarrassment amongst those responsible.

Much has been said in the days that followed the incident about the way in which such a mistake could have been made. Aside from the general panic, it has the extra element of “cry wolf”, where, if the alert is sent out again, those receiving it will now view it with a level of skepticism, instead of immediately acting upon the advice – something which is crucial in the estimated 20 minutes that it would take for a nuclear missile to reach Hawaii from North Korea.

Aside from the social or political elements of this situation, it also raises some questions around the design of the system built to send out these alerts, and how to ensure that users can ensure that the intended drill of “test” or “live” messages are being run. Two luminaries of the design world, Don Norman, author of Design of Everyday Things, and Jared Spool, founder of UIE and the Center Centre have both written insightful pieces on their views of what went wrong, and how it can be prevented in future by the use of better design principles. Writing on Co.Design, Norman’s piece focusses on the fact that we like to blame people, rather than poor design and that the system should have been thoroughly tested before it went live. Spool’s piece on Medium focusses on the fact that the system incorporated poorly chosen file names, as well as poorly designed software.

Both pieces come to a similar, and vital conclusion. When we design and build a system, we should always consider the possibility of what it will be like for someone to use it under stressful conditions. We may not ever come to the point of designing alert mechanisms for incoming nuclear missiles, but we should still consider how easy our webpage, app or system might be to use if the user is pushed by a tight deadline, for example, or is being distracted in some way. Interestingly, my workplace at this very moment, is incurring stress upon my colleagues and I, as work is being done on the roof, and we are frequently subjected to loud bangs, or the sound of hammering and drilling. These interruptions frequently distract us from what we’re doing, causing us to lose focus on where we were with our work, and having to spend time reacquainting ourselves with the task at hand. In this situation, it is common for us to make mistakes as our brains make incorrect assumptions, and we then have to realise those mistakes, and correct them.

So, how do we design for these stressful situations? Thankfully, much of this is already incorporated into the skills we learn in User Experience Design. Giving structure to pages and forms, giving visual dominance to important elements, and clearly labelling and colouring key features can help the brain realise what needs to be done more quickly. We also need to consider what the implications would be if a user made a mistake. How easy would it be to choose the wrong thing? Can an error be easily rectified? Does the system indicate clearly the user’s selections, so that they can go back and fix it later? We can even test these things ourselves – take a prototype or a test version of the system, and go and sit in a busy or noisy environment and ask people to try it. Compare this with people in a quiet, calm place, and see if there is a difference in successful outcomes. The more we trial the system or software, the more sure we can be of its success. We can say that good design and testing can improve revenue or experience, but some day, in the case of the Hawaii Missile Alert, it might just save our lives.

A new design for The Guardian

This morning, The Guardian, the UK based newspaper, revealed a new design for their website and mobile apps, in conjunction with their release of their newspaper in a tabloid format, instead of the original broadsheet. Naturally, the design decisions of the team at the Guardian have been analysed, over and over, throughout the day by designers and readers alike, giving their opinions about whether they think the new look is good or bad.

Continue reading

Springer Healthcare

Logo for Springer Healthcare

Developing an app-based solution for Pharma Sales

  • Client
  • Objective
    • Designing and producing an app-based solution to improve pharmaceutical industry sales
  • Work type
    • UX Design, Pharma, application, local team
  • Timeline
    • Sep 2012 – Sept 2013
  • Team
    • Front End Developer/UX Designer (me)
    • UI/UX Designer
    • Project Manager
    • 3 person development team


I was originally brought onto the Springer Healthcare software development team in September 2012 as a Front End Developer, responsible for coding interfaces for projects using HTML, CSS and Javascript. However, during my time working from Springer Healthcare, I was enrolled in a two day UX course from Userfocus, with my colleague, Robin Hayward, the UI Designer on the team. From this, we learned the basics of how to conduct User Research and how to use the findings to inform the production process.We then used what we learned on our next major project, creating the MediLib product.

Medilib was created with the idea of facilitating the sales process of major pharmaceutical companies, by providing materials that educated Healthcare Professionals (HCPs) about their products, while also providing materials that allowed the HCPs to learn latest developments, thinking and opinions in the field of medical science.

Understanding the Pharma Sales industry

Part one

In order to get a picture of how the sales process worked, Robin and I set up a programme of research.


We needed to talk to people who had experience of the Pharma Sales industry. As we didn’t have direct contact with the clients themselves, as sales of our product went through our own Sales Team in Springer Healthcare, we reached out to contact actual Sales Representatives. However, we had some difficulty getting hold of working Sales Representatives, and so worked with members of our own Sales Team, some of whom had previous experience working as Pharma Sales Representatives themselves.

Our analysis of how to conduct user interviews, weighting input from different subjects

Our analysis of how to conduct user interviews, weighting input from different subjects

In the end, we got to talk with four current Pharma Sales Representatives, as well as six other colleagues, who had previously worked in that role. We asked them questions, including the following, to get a picture of their working life and the challenges they face:

  • Could you describe a typical day in your job? – getting background on their working practices, as well as analysing areas where problems might occur, or how we could provide something that may advantage them.
  • Could you list five of your daily core goals? – understanding the key objectives of their work, and measuring how successful they are in achieving them.
  • What are the things you currently find frustrating? – focussing on the problems they face, which we could produce solutions for.
  • If you could change something, what would it be? – Getting further insight into what they view as problems, and deriving the user needs from their suggested changes.


From this, we made a number of discoveries:

  • Sales Representatives have to employ complex tactics to encourage Healthcare Professionals (HCPs) to buy their products – In many countries, outwardly advertising drugs and other products to Healthcare Professionals is not allowed, and so Sales Reps have to promote their products by providing the HCPs with literature that updates them on the latest developments in their field, with editorial content that promotes the Pharma companies’ products.
  • The experience is very different in different countries – In countries such as the USA and UK, HCPs have little time to spend with Sales Reps, and are quite skeptical about them. In other countries, such as Mexico, the publications provided by Sales Reps are quite valuable to the HCPs, as they may be the only updates they get on the latest developments in their field, and so they have more time and attention to spend with them.
  • Drugs have a “sales lifespan” – New drugs will be more interesting to HCPs than drugs that have been around for some time, and so promoting them will be easier than promoting older ones.
  • Sales Representatives have to navigate complex legal requirements – as well as providing information on the benefits of a new drug, Sales Representatives have to also provide information on side-effects and liabilities associated with the drugs which they are trying to sell.

Communicating our findings

Infographic showing some of our key findings

Infographic showing some of our key findings

My colleague, Robin, put together our findings into the infographic above, which helped us not only communicate our findings to stakeholders, but also printed out into an A1 size poster, which we could place on the wall of the office, ensuring that our findings were kept in the mids of our production team as we worked on the project. Alongside the infographic, I also created some personas, to help summarise our findings in more detail, based upon the different roles and territories which our users occupied:

The combined personas showing different requirements based on user roles and location

The combined personas showing different requirements based on user roles and location

The personas and infographic on the wall of the office

The personas and infographic on the wall of the office

Taking these findings, we then held a day’s worth of exercises with stakeholders and the production team, exploring the requirements fully, and starting to define solutions for the user requirements:

Using an empathy map to help stakeholders understand the standpoint of a specific user types

Using an empathy map to help stakeholders understand the standpoint of a specific user types

Understanding red routes - key user paths which are important to the specific user type

Understanding red routes – key user paths which are important to the specific user type

Having gained a better understand of the specific needs of each user type, we held ideation sketching sessions, asking everyone involved to sketch out solutions that might assist with the user requirements. We then combined all the findings, along with the explorations and solutions during the workshop, and devised an overall production strategy:

Devising a production strategy

Part two

In order to provide a complete end-to-end solution to address user and business needs, we split the solution into three stages, which would provide a way of ensuring that Pharma Sales could get information in front of Health Care Professionals more easily:

  1. Creating a web interface – this would provide a simple way for Sales Reps to deliver materials to HCPs, just by providing a link.
  2. Developing a back-end system – this helps Pharma Sales Managers keep track of Sales Rep performance, and a system from which they can continue to contact the HCPs
  3. Design a library app for mobile devices – finally, this provides a way for Sales Reps to show content to HCPs in person, as well as providing a way for HCPs to easily access information after the Sales Rep has left.

Creating a web interface

The web interface, or “ePrints standalone page” as we called it, being fairly easy to prototype and produce, provided an good starting point for us to test our assumptions, and create something which could be used by Sales Reps fairly quickly. We designed it fairly quickly, creating a framework which could be built on over time, adding more functionality over time.

Whiteboard showing design planning for the standalone page

Whiteboard showing design planning for the ePrints page

UI design for the standalone page

UI design for the ePrints page

In order to access these pages, the Sales Rep would leave the HCP with either a code, written onto a card, or sent via email. This would allow the HCP to access the information at their leisure, reducing the pressure of trying to provide information during a short visit.

We built a prototype, and tested it repeatedly during each iteration, allowing us to improve our knowledge of the user requirements and ensure that we were building the right thing. We also added more functionality over time, providing not just text and a link to a document, but also video, interactive elements such as quizzes and more to help make the page more engaging.

Developing a back-end system

To help Pharma Sales Support Staff control each standalone page, as well as monitor use, we then developed a “back end” interface as a content management system, which we called “MedEngine”.

Planning the MedEngine user interface on a whiteboard

Planning the MedEngine user interface on a whiteboard

An example screen design from the MedEngine product, showing an overview of sales reps and products on offer

An example screen design from the MedEngine product, showing an overview of sales reps and products on offer

This system would allow Sales Support Staff to understand which pages had been accessed, had items downloaded or used on the page, thereby measuring success of the Sales Reps. As restrictions existed in many countries around how much a Sales Rep could give to HCPs in monetary value, in order to prevent bribery, it also ensures that HCPs do not receive too many items by removing old ones and adding new ones.

Designing a library app

To further improve the experience, we designed a library app for use on mobile and tablets, named MediLib, which allowed Sales Reps to showcase information to HCPs, as well as provide a leave behind library of items, which the HCP could browse freely, but also have access controlled by support staff

A sketch of one screen from the MediLib library app

A sketch of one screen from the MediLib library app

UI design from the MediLib iPad app

UI design from the MediLib iPad app

This system allowed HCPs to access information, even while offline, with regular updates to ensure that content access was kept up-to-date.


Part three

The combined approach allowed us to do the following:

  • Quickly putting up a solution, which could be tested and improved, and added over a period of time, to ensure that we had a modular product that could fit the differing needs of various customer Pharma companies.
  • Ensure that Sales Reps could get promotional materials in front of HCPs quickly and easily, without damaging their relationship to the HCP, and providing value that could be quickly and easily seen.
  • Provide a method to build a relationship with the HCP, thereby ensuring further sales in future
  • Become a “best in class” product solution in the field of Pharma sales.

For more information about this project, or to discuss this further, why not get in touch?

Similar projects

  • Springer Nature logo
  • Logo for Nature Nano
  • Springer Materials logo