Agile UX tips and tricks

Beyond Buzzwords: 4 Tips for Smoother Agile UX

The 12 Realistic Principles of Agile UX

6 Tips for a Successful Sprint in Agile UX

How to Write A Painless User Story

A 6-Hour Usability Test In An Agile Environment

Product Manager vs. Project Manager: Why Great UX Demands Both

Beyond Buzzwords: 4 Tips for Smoother Agile UX

Work Ahead of Developers

If UX designers are still being seen as outsiders, it pays to be diplomatic in your approach. Encourage designers to adapt to the daily routines and workflows of the developers. Familiarize yourself with the agile process and more specifically the Scrum roles and schedules.

In fact, the Nielsen Norman group recommends that the UX team act as a sort of gatekeeper role. As such, UX designers should deliver prototypes and usability testing results at least one sprint ahead of the development team’s sprint.

It’s imperative that the UX team lead the process, starting off with usability tests, user research, prototypes, and a broad idea of the overall structure of the final product. Kanban Boards can be extremely useful in establishing priorities from all sides and organizing a useful workflow.

Treat Collaboration As a Continual Process, Not a Phase

Make sure that everyone is aligned to the workflow before getting too deeply entrenched in the process. Treat documentation as a method of collaboration.

Try a “Cheese” Day

Because one of the primary principles of the Agile process is to iterate quickly and consistently, a lot of UX problems may end up getting swept under the rug. One way to address this is to make a project day specifically dedicated to eliminate “cheese.”

What is cheese exactly? Points of user friction that may not be bugs exactly, but nevertheless represent a compromise in overall user experience.

To address these issues, make a list of probable cheese well in advance, at least 21–30 days. And have the entire team contribute to the list.

Prioritize the items on said list and classify them by difficulty. Then allocate a day to run through each issue and eliminate your cheese.

Be Flexible With Standup Meetings

The 12 Realistic Principles of Agile UX

1. Customer experience (CX): We don’t just want customers to be “satisfied.” We want to design user experiences that are cognizant of both business realities and customer contexts.

2. Harnessing technological and social change: We need to define changes that we expect in the next iteration of a project, rather than just adapting to current changes.

3. Development timelines that make good use of resources.

4. Adaptive collaboration: The degree of collaboration changes from project to project. Some problems clearly fall within the purview of a particular specialist, some will require an entire team to solve, and some require sub-groups of a team.

5. Building projects around motivated individuals.

6. Effective communication across team channels.

7. Working applications and high-quality UX as success benchmarks.

8. Sustainable development: This goes back to principle 3. Some features within a specific application will probably become obsolete in future versions. New features are also the lifeblood of successful product launches. Product iterations should always be a balancing act between what existing customers expect and what new customers need.

9. Technical excellence is relative: In some organizations, like institutions of higher education or non-profits, for example, the most viable solutions might be considered obsolete in other venues. And that’s OK because we must consider price-point and organizational capacity.

10. Simplicity: Again, it depends. The simplest solution isn’t always the best one, especially if that solution neglects user, organizational, or technical realities.

11. Cross-functional teams: UX specialization is nothing to be feared. Silos are the real problem. When specialists don’t talk to one another, we get products that neglect one or more elements. As long as productive, cross-channel communication is happening within organizations, then specialization is okay.

12. Adaptable, flexible teams.

6 Tips for a Successful Sprint in Agile UX

Successful sprints in Agile UX are all about preparation.

Tip 1: Develop User Stories

“The best thing about Agile, to me, is user stories. They describe in a simple narrative way what the functionality of the system being designed needs to be.”

A great way to go about developing and refining your user stories is to meet with Product Managers before each sprint and double check that there’s a shared vision between your PM, UX, UI and design teams.

Tip 2: Define Necessary KPIs and How to Get Them

To use an example user story Joseph described in his post, a Doctor in New York may need to electronically send prescriptions to out of state pharmacies. With this user story in hand, you should already be thinking about what key deliverables you’re after and what the best way would be to achieve them.

Tip 3: Don’t Recruit During the Sprint

This is why successful agile teams recruit their participants before the sprint so that on Day 1 you’re tracking results, and not scrambling to meet sample size or demographic requirements.

Tip 4: Make sure the decision maker believes in the purpose of the sprint

It’s very frustrating to come up with a great solution and have it shut down. This tends to happen in bigger companies.

Tip 5: Let everyone know (involved in the sprint) that any form of sketching is ok

It’s not a design contest. Engineers are usually uncomfortable with drawing, your job is to put them at ease.

Tip 6: Think about user interviews

When it‘s time to do user testing interviews with your prototype, I suggest you find a savvy friend that can help you run them — even more so if you designed or coded the prototype. It’s easy to become attached to your solution and steer the interviewee in your direction. Make sure you record the interviews and share them with the rest your team, especially with the people that couldn’t be part of the sprint. The process is also partially about having everyone buy in and sign off on the solution.

How to Write A Painless User Story

A user story is the gold standard for communicating product requirements to all team members. They’re brief, specific, and quickly understood.

Every user story includes three main characteristics:

1. It tells the story of the problem or need that the user will solve through a particular piece of product functionality.

2. It’s meant to be a living story that can be updated and modified as a project evolves

3. It provides sufficient information for developers and designers to understand the functional need, but doesn’t go into the details of how these should be addressed from a technical or design perspective.

The User Story Template

A user story has three main components:

Summary: The summary is basically a statement that tells the story of what the user would like to achieve. The general format for the summary is:

As a user I can <perform a certain action or achieve a certain goal>

Details: The details piece of an Agile user story spells out how particular functionality will work. Using the example of platform for location doctors, let’s take this user story:

As a user, I can create an account

We can then write out the following details:

i. User clicks on account creation option

ii. User is prompted to fill in the following fields:

First Name

Last Name

Username

Password

Priority

The priority index helps the product manager ensure that the Agile product team is focusing on the most important features first.

You can present the priority in three different ways:

• T-shirt sizing: S, M, L (small, medium, large)
• Urgency index: L, M, H (low, medium, high)
• MoSCoW rating: M, S, C, W (Must, Should, Could, Won’t). This method of prioritization is mainly linked to DSDM, another Agile methodology.

Several factors influence the priority index of a user story:

• Business objectives: A user story that directly influences a company’s revenue objectives or another KPI (such as reducing support tickets, customer retention or acquisition rates, churn rate, etc.) will get a higher index than stories that are nice-to-haves
• Functional dependencies: If multiple user stories can only be implemented after a particular story, then the latter becomes critical and gets a higher index value.
• Dev time required: If a user story is evaluated by the dev team as being quick to implement and it’s essential for achieving business objectives, then the story moves up in priority.

User Stories and the Product Backlog

Once you’ve created a user story, it becomes part of the product backlog. The backlog is the collection of user stories and it’s a living document that is updated as user stories are completed. In addition to the main components of a user story that I’ve listed above, the backlog may also contain information such as:

• Status (in-progress, done)
• Sprint (sprint to which the user story is assigned to)
• Comments (any additional supporting information for the designer or developer)
• Mockup/screenshot (this can be a link to a sketch or final photoshop design of a screen)

How User Stories Improve UX Design

The beauty of the user story is that it describes the functional need, without diving into details about technical or design implementation.

When you think about it, UX is really one huge puzzle. A user story allows the designer to see all the individual little pieces required for the product.

Thanks to the Agile process, the designers, developers and product manager can all discuss any potential concerns about each story during the sprint planning session.

A 6-Hour Usability Test In An Agile Environment

10AM: Planning

• Determine tools
• Determine what to test
• Select Users
• Select Tasks
• Select the Study Type (Between Subjects or Within Subjects): With little time to collect a larger sample size, we chose a within-subjects study, which allows you to detect statistical differences with smaller sample sizes than a between subjects study. (If you’re not making a comparison, you skip this step).
• Define Metrics
• Develop Pretest Questions: We developed a few demographic questions to get some idea about the participants.
• Develop Posttest Questions

11AM: Study Programming

With the users, tasks, questions, and metrics defined, we programmed these details into UserZoom.

12PM: Pretest

Next, we had someone in our office — someone unfamiliar with the tasks and the study — run through the study and think aloud. This led us to reword a few tasks and questions.

12.30PM: Data Collection

We asked our favorite panel to send participants to take the study. Over lunch, the participants have completed the study.

2.30PM: Analysis

For the next 90 minutes, we pored over the data and watched the videos from Usertesting.com and UserZoom.

• Determine Statistical Significance: We compared the task metrics and then looked at answers to the preference question.
• Watch Videos: The videos indicated which interface elements were working and where users were getting lost.

4PM: Happy Hour

While every metric didn’t indicate statistical significance, we had enough evidence that the design was moving in the right direction, and we could see how it could be further improved.

Product Manager vs. Project Manager: Why Great UX Demands Both

What is a Product Manager?

The product manager handles the big picture of the product development. Often the product itself is their brainchild, and their focus is less on the day-to-day endeavors and more on the overall strategies to make the product successful in the market.

A product manager’s skill set lies within understanding the market and the customers. Main responsibilities include:

• Strategic idea creation — Drawing on their knowledge of the market and customer base, they must brainstorm new product ideas to target business goals.
• Feature creation — Likewise, they suggest the features to increase the chances of success.
• Staying current with market trends — Basic marketing skills.
• Direct contact with the customer — Speaking directly with target customer groups to deliver what they want with more precision.
• Dictate KPIs — State the performance indicators on which a product’s development and success can be measured.
• Prioritize release dates — For products, features, and updates.
• Create “blueprint” documentations — i.e., use cases or user flows.
• Prioritize bug lists — Determining which bugs needs to be fixed first, and which can wait.
• Work with engineering — To make sure their ideas are feasible.

What is a Project Manager?

Project managers deal with the logistics: financial concerns, team resourcing, and meeting deadlines and scope.

A project manager’s most important skill set lies within understanding and organizing the team.

Main responsibilities include:

• Setting schedules and deadlines — With their understanding of their team’s abilities and limitations, they set realistic project milestones.
• Monitoring the budget — They keep the teams within financial constraints.
• Cross-team organization — They act as liaison between all departments, both as manager and messenger.
• Resource management — Determining where resources are needed and allocating them.
• Problem resolution — Smoothing over any personal or process issues.
• Status updates — Keeping stakeholders, as well as other departments, informed on the the product’s status.
• Risk management — Foreseeing and avoiding potential risks or setbacks.
• Scope management — Making the tough calls to balance time, cost, and quality.

Why You Need Both

Product managers create the roadmap communicating product strategy. Project managers create the timeline to execute each necessary step.

Both jobs require different types of thinking as well:

• Product managers lean towards the abstract and creative.
• Project managers, on the other hand, seem to be the exact opposite. They think in concrete and logical terms, taking the abstract ideas handed to them and turning them into realities.

The two roles complement each other. Great product design is the equal result of tension and collaboration.