Case studies Ruth McAfee - Internet Portfolio

I have used this section to describe the experience of being a UXer. All words, images, diagrams, documents and prototypes shown below are 100% my own. Additional or more detailed examples can be provided on application.

Photograph of a builder's overflowing toolbox

Screen grab of an issue described in Jira software for an Agile team

Collage showing a partial interview script and online meeting thumbnails

Diagram to map and compare old and new flows

A strategy for Human Centred Design

1. Define the problem-space

A goal, an end state or a problem to solve is the first requirement for developing any strategy. Starting with the definition of a problem, the following stages describe ways I help clients deliver more effective, customer-centric, stakeholder-endorsed outcomes for business. When the information has been provided from another source, dismantle it and play it back. Question every assertion, acknowledge the assumptions, be wary of every possible bias. Know where the problem is and where it has come from. Seek to know why is it a problem and for whom.

2. Determining the best approach

My User Experience toolbox is full of useful templates. Some are on high rotation, in a constant cycle of customisation and refinement. Others might be highly contextual and not used as often. The important thing, is to know what they are for, and how to get the best from them. At the beginning of a process, in conditions of extreme ambiguity, it can be difficult to see a way forward and to find the best approach. I keep my focus on the customer - the person and the purpose. We are human-centred designers and we start by gathering information, asking questions, finding empathy, and observing.

3. Research planning

Articulate the purpose, focus, and definition of done. The screenshot shows an Agile task that has been catalogued in Jira. While Agile may share principle similarities with UX, (such as simplification, iteration, componentising larger tasks) it is nevertheless, not always a comfortable fit in our workflow. Research takes time, and as indicated on the first slide, accounts for most of the time we spend before arriving at a wireframe. Like any other plan, research has a known beginning and a desired end, with decision activities in the middle. In Jira, I have described the issue to initiate the task. I have identified the topic, and the definition of done (DoD). In doing this, I pursue a shared understanding of the process, the rigour, and the method which provides the baseline for my decisions and sets expectations. At this stage, the shared understanding is as important as findings and recommendations delivered later on.

4. Sticking to the plan

Sprint timeframes and incorrectly sizing tasks for ambiguous pursuits can impact the process. At this mid-point it is important to back myself, back the plan and the planning, and be constantly referencing the purpose, topic, project goals, and context for all the twists and turns that present. With good, transparent planning the process will hold up and can accommodate changes in knowledge that may affect the purpose or goal. HCD is not linear. A research plan is not a blueprint. The details of the plan may change or the findings might reveal something not yet seen. The most effective plan will scale and keep the process moving.

5. Follow up and synthesize the data

So. Much. Data.
During COVID-19 we have relied on digital collaboration tools more than ever before. The image shows a collage of virtual sticky notes on multiple Miro boards. At first, the data is collected as notes taken quickly, during an interview. This initial step is verbose and haphazard. What follows is a repeating process of sorting and clustering these observations and notes into topics, ideas, and relationships; while taking care to preserve the intent and context of the research activity. Little by little the insights that we were seeking, and that will authenticate the purpose, emerge from the volume of outputs - sometimes looming large as themes, sometimes as outliers of varying significance.

6. Report and document findings

Review the planning from step 3. Share findings from step 5 and deliver what was promised. As we move into the design phase, insights will guide the next steps. In this example I have mapped an old user flow to the proposed new one, keeping the relevant user stories, notes from the previous step, and links to supporting documents close by. I don't prescribe the tools or the presentation method. The best tools are the ones that our audience (stakeholders and extended team) are already using. UX is not limited to the needs of the end state audience, and meeting our audience wherever they are, is foundational to good design. At this opportunity we can validate a brief or a user story, we can get buy-in where there wasn't any before. We might even decide against a planned activity. Powered by research and a broad understanding of the problem, this is HCD.

7. Recommend next steps - wireframe

The wireframe is used to visualise the design intent, rationalise the research outcomes, and provide a platform for the earliest user validation. Depending on the size and complexity of the issue, the resources, and the design maturity of the client, the presentation may differ while its value is unchanged. With minimal decoration, the wire is quick to produce. It focuses on the job to be done, and the ease of movement between minute stages of that task. But, like everything else in the UX / HCD process, the purpose, focus, and goal of this artefact must be understood before its value can be realised. For some people, the low fidelity of a hand-drawn wire is in itself distracting and too abstract to be useful. The preamble needs to acknowledge this, provide a definition of the scope, and screen for meandering points of view. Sometimes, when the client has an established and comprehensive design system, a clickable (medium fidelity) prototype may be just as quick to draw, and easier to onboard.

A case study in Agile UX

Much has been written about integrating UX into the agile process but...

I specialise in UX, and an interpretation of Agile Scrum methodology has been the preferred working cadence of every team I have joined in the last 7 years. No two implementations have been executed in quite the same way, and yet the challenges for UX are almost identical.

The first of these challenges is planning. Ideally, UX activities need to be completed at least one sprint ahead of design, which needs to be at least one sprint ahead of development. Workable roadmaps depend on a product backlog created with long-sighted forethought and vision - feeding into diligent sprint planning. (I'll explain why on the next slide.)

The second impediment for UX in Agile is the assignment of time to an ambiguous task. When productivity and performance are being measured by the number of tickets completed, and tasks are being assigned like a hand of cards to other team members, UX is put in an awkward position if poorly understood tasks remain tightly bundled and under scoped. As illustrated above in the HCD process, 'research' is an umbrella term for many activities - that all take time. Research activities usually include a current state assessment, identification and validation of the problem, and planning (which may involve writing a script, recruiting participants, and administration of privacy and security policies), all before the 'research' even begins.

The long-sighted backlog

Planning: UX activities inform UI and content design, which impacts navigation and IA, which comes before development and engineering. This is why UX activities need to coordinate with dev and engineering at the planning stage. In Agile product development, best practice is to share early and often, validate and revise - across each of the team functions. Unproven assumptions may waste hours of design or engineering time if work begins too soon.

Though its widely accepted that UX research will substantiate theories into validated stories, the right time to integrate UX into project management is not well understood. Starting with the product vision or end-state which was likely captured in a workshop with stakeholders, the product backlog records the outputs as requirements. Now we know where we are going, but we still don't know how to get there. Starting with the product backlog we need to be better at reconciling this. Including research spikes for UX to evaluate and determine the approach (such as steps 1 & 2 from the HCD process outlined in the study above) will result in more streamlined, engaging, and democratic sprint planning.

Estimates and sizing: I find that the variety and scope of UX tasks - which almost always fall into some kind of journey - are not well served by the punctuation of user stories or issues in Agile scrum. User stories are static, binary even, like a photograph stripped of its context. Agile User Stories were invented for the production of code in software development. By comparison, User "Experience" relies on wholistic recognition of the situation, the need, and the job to be done - or in a single word, empathy.

Addressing the problems, and evaluating choices

User Experience ~ User Empathy. When addressing the problem of estimating and sizing - as identified in the previous step, one simple approach is to replace user stories with job stories. Recently, while on contract at the NSW Department of Customer Service, I saw "Job Stories" in action. I first learned about these in the book "Content Design" by Sarah Winters published in 2017, where she describes the "Job Story" beginning with a situation and followed by a task, compared to user stories that address the audience first.

If you're reading about this for the first time, it might seem strange for a UXer to remove 'user' from the story, but in UX we ALWAYS think of the user first. The difference to me is that a job story also considers the users' situation, and thinks more broadly about what it is they need to get done. This is useful in understanding and preparing for a users' next move, or in bringing forward the context that has gotten them this far.

A second approach for mitigating sizing issues is to incorporate research spikes within the product backlog. A research spike provides visibility of the type and extent of research tasks to be done, while removing any uncertainty about when to incorpoate UX to the project workflow. Hence, the benefits to the team of this approach, are doubled.

The reality is brutal. It's the assignment of an issue estranged from its epic, because that's how code is done. Human centred design is not code. Without context, HCD is an oxymoron but the designer's responsibility doesn't change. We work long for less.

Agile UX is for projects is for product methodology

A project kicks off. The process (for delivering the thing we agreed to) has begun - except - before it exists, we can't know for sure if the market will like it.

UX (HCD) is precisely the methodology to alleviate this risk and to accurately refine and condense opportunities before engineering them.

UX activities, embedded from the outset are complementary to Agile project management. Let's do this.

References:
Content Design by Sarah Winters (formerly Sarah Richards)
Designing content for customer mindsets
Atlassian - Agile Manifesto
Lean UX by Jeff Gothelf and Josh Seiden