Author: Jim Glodkowski

Categories
Uncategorised

The fragmentation of UX

Image showing a pane of shattered glass
Image showing a pane of broken glass
Is UX splitting in to ever-smaller pieces?

I’ve seen an an increase in articles and blog posts talking about splitting UX into increasingly smaller “UX fragments” recently.

There are many examples of this – some I’ve seen in the last week or so include…

  • OOUX
  • Business driven UX
  • Enterprise UX
  • Marketing UX

I’m not criticising any of these authors or the fragments which they write in support of. There is a lot of great thinking going on in these articles. But I guess I am sounding a note of caution about narrowing focus too much on these fragments.

Why UX fragments could be a problem

UX is a form of design, and design is about solutions to problems. Providing a very narrow solution that focusses on a fragment of UX may not always be that helpful.

As a Freelance UX Designer, some of my clients don’t really understand UX as a discipline. (Why would they, they have their own business to run after all).

They often care even less about the UX fragments mentioned above. Their expectation is that I solve ALL of their problem. Not just the bit that aligns to a narrow discipline I’ve chosen to specialise in, and leave them with a lot of gaps to fill in.

This means I often end up wearing several different hats. On any given day I might be a UX designer, a UI designer, a User Researcher, a Service Designer, a Product Designer or a Business Analysis.

If you’re an agency looking to hire UX

If you’re an agency looking to hire either a permanent of Freelancer UX Designer, it’s unlikely  you’ll need someone who focusses exclusively on one of these fragments unless;

  • You have a specific need in this area
  • You have a team of other people who can fill in the gaps

If you’re a client looking to hire a UX agency

The same is probably true if you are a client looking to hire a UX agency for your business.

Unless you have worked extensively with a User Experience Designer in the past, you may not find a huge benefit in hiring an individual or an agency who focuses exclusively on one of these UX fragments.

If you’re looking to break into the industry.

If you’re new to the industry and looking to get your first job, I personally wouldn’t recommend you try and focus on one of these fragments. If you land a job in one then great, but it’s likely to be more advantageous to you to try and find a role which is broader. This will give you the exposure to a variety of UX projects and experiences – it will also allow you to see what suits you and where your strength lie before narrowing your focus (slightly).

If you work with product teams

I can see more scenarios where focussing on a UX fragment can work in product teams. Especially larger teams which are operationally optimised to accommodate these different disciplines.

It may be that these are very niche roles, which only exist in teams above a certain size or within a very specific industry.

And as designers taking these roles could end up making us over-specialised to the point of that transitioning out of these industries os difficult.

Parallels from development.

Because I’ve been in the industry for 20 years or so I can remember a similar thing happening with development. Developers used to be one person and that person was called a Webmaster (yes, really).

Over time we got developers, then front end and back end developers. These then split down further into specific languages, or specific platforms and were accompanied by the growth of additional disciplines like dev ops. (I’m sure some developers can provide way more detail than me on some of these.

So are UX fragments bad?

Quick answer is no. As I mentioned at the top, there is some good thinking happening in these areas which will push the whole industry on, and we shouldn’t disregard these.

There will be exceptions. But unless you fit a very specific criteria, I’m not sure focussing on one of these fragments is a great idea.
In the same way that development eventually came full circle to having “full-stack” developers, in most situations, we can best serve our clients by being full stack UXers

Categories
Case study

Building journey maps for AstraZeneca

Final version of the journey map (blurred to preserve anonymity)

Overview

These are some journey maps examples I created to better understand users and the actions they went though to provide monthly updates to a business-critical resourcing tool for AstraZeneca.

Quick note on language, these are also sometimes referred to as customer journey maps or user journey maps, but they are very similar.

Benefits

Journey maps are great for distilling processes down into a format which is easily understood by everyone on the team.

These also allow easy identification of the stages of the user journey and highlight user pain points.

They also allow us to uncover any issues issues in the journey – addressing these early saves a bunch of time in development.

For example, I often uncover service design/ business process issues which fall outside of the tool itself, but which need considering to  to ensure our solution is coherent and ultimately successful.

By comparing these maps across different user groups I can prioritise opportunities for improvement in a way that works for the user and the client.

You can read more general information in journey mapping (as well as the closely related experience maps and service blueprints on the excellent Nielsen Norman Group website.

Final version

Examples of the final journey maps are above. A more in-depth walk though of how we arrived at this journey map follows…

How we got there

User identification

From previous user research I’d already identified our user groups, and how they fitted into the wider business process around the product.

It had become clear that there were two key groups we needed to focus on, which we called;

  • template creators &
  • template completers.

Draft journey map

We drafted what we thought were the key stages of the journey for each user group.

Against each stage of the journey I considered the specific information we needed to capture. On this project, this was;

  • Specific actions (we knew high level but not detail)
  • Touchpoints (people/processes/platforms)
  • Opportunities for improvement
  • Owners of each stages OR…
  • …additional stakeholder we might need to engage with.
Miro screenshot showing collection of raw data from user research sessions

Discussion guide

I drafted a discussion guide for client approval. This was to ensure agreement on the areas of research, and to provide a guide for the user researcher (me in this case) to make sure all agreed areas were covered in the user interviews.

Finding participants for usr research

We needed to choose our participants carefully. There were many areas of the business we might have sourced them from.

But we wanted to make sure the participants we chose would be representative of the variety and diversity of the user groups they represented.

User Research

Having sourced our candidates, I performed user experience research . We choose remote moderated as the user research method, which effectively means walking the candidate through their journey via MS teams.

Post it note observations were added to our draft journey map in the approximate part of the process they corresponded to.

We also captured multiple screenshots of related service, touch points and tools which supported our users on their journey.

Miro screenshot showing collection of raw data from user research sessions

How to synthesis user research data

After collecting all the data from the user research sessions, I performed some analysis and synthesis of the raw data which this time round involved:

  • Cleaning and sanitising the data
  • Refining our draft user journey from the data we collected in research
  • Identifying for recurring themes or common patterns
  • Extracting opportunities from verbalised or observed behaviour

These findings were summarised into a short report which was delivered to the client

Categories
Case study Uncategorised

Heatmaps case study

Summary

The client wanted a way to report on resource usage across their drug development portfolio.  

This encompassed tens of thousands of people and hundreds of millions of dollars of revenue.

The approach

It was clear that the scope of this project was somewhat ambiguous so we initially committed to a discovery phase only. 

Depending on the findings from discovery and the direction the project took we would evaluate the best use of time and the most effective deliverables.

Research

Business analysis

The first task was understanding more about the business – what was the specific problem they had and how would we measure success. This involved multiple workshops and interviews with key business stakeholders and users.

Report analysis

There was already an existing offline process in place which made use of multiple excel sheets.  We needed to do a deep dive to understand more.

User identification

Our research uncovered four different user types. 

  • Administrators
  • Resource Council users
  • Function level users
  • Higher management.

We interviewed users in each group to get more complete understanding of their specific problems.

We additionally sat in on monthly resource meetings to observe how existing reports were used “in the wild”.

User Research

vbvbbbbvbvbvvb

A change in direction

From our research it became clear there was more to this project. In order to succeed we needed to broaden the scope of our engagement to consider:

  1. Data collection
  2. Service design
  3. Change management
  4. Enterprise level IT solutions.

High-level prototype

Unconventionally, the decision was taken to develop and test a high-level wireframe prototype as part of the discovery process.

The objectives of this were as follows

  • Demonstrate a possible way of automating the current (labour-intensive) process
  • Sense-check that the work done to date is heading in the correct direction

Prototype user testing

Initial user testing was completed against the high level prototype. 

Affinity mapping was used to organise insights, and a summary deck produced and presented.

<image>

Future roadmap

The summary deck was well received, and based on this a strategic roadmap was drawn up to indicate how to progress the project. 

This includes;

  • Workshopping
  • Co-design sessions
  • Customer journey mapping
  • Continues wireframing and user testing
Categories
Case study

User testing

Benefits summary

This was a really lightweight and quick way to get feedback which uncovered some fundamental flaws in the approach

  • 3 x critical factors which would have derailed the project
  • Multiple opportunities to tighten up and improve our messaging to communicate more clearly with our target audience

Client feedback

“I thought it was great, and a very critical step.”

“Design of interfaces and ensuring that content is presented in a digestible and accessible way…is such a fundamental need”

“I certainly saw the merit and am already planning on carving out additional budgets to include these types of focused user feedback.”

Client feedback from User Testing session with AZ

Background

We were contracted to develop some ideas for a medical website aimed at pathologists in the US. The purpose of the site drive implementation of HER2 testing, which can have a profound effect on the treatment of breast cancer.

Based on existing research, some wireframes had been created, but we were keen to understand if these would resonate with working pathologists who were the target audience for this site.

Recruitment

Recruitment of pathologists (especially in the US) is extremely tightly regulated, and payment for services can be seen as inducement/bribes, so we had to be very careful from a legal perspective

With that in mind we contacted a specialist(M3) who handled the recruitment and legal/regulatory issues, and screened the candidates for suitability.

Recruiting pathologists is not cheap! – We ended up with 5 who we spoke to for roughly an hour each.

Discussion guide

Prior to the session we created a discussion guide with the client.

This highlighted the key areas we wanted to explore so we had a consistent line of questioning across all candidates while retaining the flexibility to probe deeper based on individual candidate experience

Running the session

In terms of set up we generally kick thinkgs off with a MS teams call before using LookBack.io for the majority of the session. Starting in the teams channel allows us to trouble shoot any connectivity or tech issues the user might have. We keep this available during the call in case of emergencies, but mute it during the main discussion.

Links to the prototype are available through Lookback (we’d set this up previously) so the user can jump straight into it

Client management

With these session, there is often a lot of interest and various people wnat to be involved. Typically we run an account for an assistant to speak to the facilitator during the session. This assistant screens the comments being fed through to the facilitator (it can get pretty overwhelming) while ensuring any relevant feedback from the stakeholders is passed on

Video review and write up

Post the session we reviewed the videos collected on Look back.io. this allowed us to retrospectively sense check, and clip videos to give specific examples to clients to illustrate the points.

Over the course of the session we found a number of themes emerging (detailed at the top of the page) which we presented back to the client in a power point format.

Categories
Uncategorised

Planning a UX discovery workshop

Discovery is a word which gets thrown around a lot at the moment. Almost as much as the A-word.

I’ve run a bunch of discovery sessions over the last few years,and I feel like the more I do the more the opportunity is and some have definitely been more successful than others. 

So here are my top 8 pointers on things to spot/things to avoid.

There are tons of good material written about how to actually run a session, so I don’t want to rehash that too much.

Consider these top-level pointers on how to approach rather than a play by plan breakdown for the day

1. Give the preparation the attention it needs.

This is likely to be the first contact a lot of people on your team will have had with the client. It’s also an important opportunity to put down a marker in terms of ground rules – approach and expectations. These things don’t just happen on the day. They need thinking through and preparation in terms of how you might land them


2. Get the right people in the room

This might sound really obvious, but it’s really important. Spend the time figuring out before who needs to be involved. Chances are you’ll be starting late so there will be pressure on the team to begin as soon as possible. However not including all the right people at the start is a sure fire recipe  for longer term pain. 

I once spent a year building a site only to launch it and the chairwoman’s husband convinced her to take it down after one week. Turns out he was a powerful stakeholder and we should have included him in the discovery process.

3. Don’t go too “cookie cutter”

While it’s good to have a template you can cherry-pick from, there will be elements which have to be bespoke each time. That is the value that you are adding – If you were just dusting off a PowerPoint each time, anyone could do it.

Recognise that the value add takes TIME. You need to give you and your team a good run-up to this. 

4. Compare notes with your team

Happily, the continuous improvement mindset is now everywhere. So there is a (good) chance that someone in the team will have come up with a different way of doing things since the last time. 

Take the time to sit down with the delivery team beforehand and make sure everyone understands how each team will work before you go and tell your client.

5. Manage up in your organisation

New projects tend to be shiny for your client and for your own business. It’s likely that a bunch of people are going to want to be involved for all kinds of valid reasons for example;

  • New business team may have handled the work and want to be there for continuity
  • C-level people who may be there for reassurance/ “gravitas rolling out the big guns”

Try to align all these people internally before so they are bought it. Aspirationally you could also lay down some ground rules in terms of what you need from them. 

The end game here is to try and avoid a situation where a Hippo wants to impress the client and end up overpromissing to the client and the team then spend the rest of discovery

6. Be able to articulate your process but…

Be really clear with your team about what the next steps are for the project

7. But don’t call it a “process..”

The client has just engaged an agency. Chances are they are super excited about it. And they are expecting to be wowed imminently with creative thinking and clever solutions. Hearing you bang on about your seven-step process and associated roles and responsibilities associated MIGHT not be exactly what they want to hear at this stage

 There is nothing better at killing the enthusiasm the client has.

8. Know your audience

Don’t put a load of marketing people in the same room as a load of tech people and expect them to stay engaged when the conversation turns to infrastructure, APIs, and regression and blackbox testing. Try and keep the conversations focussed around their needs. The figuring out how will come later