Category: Uncategorised

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 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
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