How to optimize the UX process for projects with tight deadlines?

Question

I'd like to put the MV(UX) case on the table here and get your insights about how projects that demand a short, viable, and functional iteration of the UX process would go for NEW projects (Keyword here is "NEW") and how many resources . "short" is 2 weeks which is the usual time allocated for a scrum sprint of development.

Answer 1

Not generally recommended since you can't really do enough research in the beginning or enough testing at the end of each sprint to influence and impact design decisions too much. However, as a 'cut-down' version of the full UX design approach I can offer some general advice, assuming that the team is already familiar with Agile methodology and reasonably experienced individuals involved.

• Dispense with UX as a jargon and don't obsess over the methodologies, instead put down effort for design that incorporates both analysis, design and technical aspects, with the analysis and design assigned to the UX person while the technical part is assigned to the developers to evaluate the design solution and whether it is technically feasible to implement. The analysis can also be used to review technical decisions as well as testing that picks up changes required. Less jargon and more streamlined workflow is what you need, not how to integrate UX into Agile and/or Lean when you have enough things to worry about
• Document requirements in a way that business, technical and design team members as well as stakeholders can understand because overhead communication time takes precious resources from where you need it more with the short project and sprint cycles.
• Regardless what other people think, find time to talk to at least one actual end-user, you will be surprised at their contribution and insight in reducing the amount of time and effort by making sensible suggestions to the scope of work and the design details. Since you will be making lots of assumptions in the initial design without a lot of research, any chance you can get to validate assumptions will save you lots of time later. Do any 'guerilla testing' that you can spare time to do, because it is always worth the effort.
• DO document, no matter how basic or trivial it might seem, or the time it might take up because things that you do right at the beginning will save you a lot more time and effort later, especially when you have to introduce new resources or if there are personnel changes later down the track; obviously don't document more than you need to and chew up precious work time, but think of documentation as part of the effort required later down the track when you have to make design decisions or changes.
• Throw away your ego and be prepared to 'pump' out a MVP, or get out of the way because in projects with tight deadlines and resources anyone that gets in the way will just get run over by everyone else. If this is not your kind of project then be prepared to leave early. Project Managers prefer to make changes early rather than later in the project, much the same way business stakeholders like to introduce changes to requirements later rather than earlier in the project.

Answer 2

On projects that can't afford real UX efforts, I shift my role to ensuring that the basic "UX 101" rules are followed, just making sure that no egregious usability principles are broken.

Wireframes are likely to be quick and rough, so the UX Designer needs to keep a close eye on the project during visual design and development to answer questions that the wireframes don't answer, and to make sure that the hasty design decisions are actually good, as they're implemented.

(You ask for number of resources - UX resources, I assume. I imagine more than one would be unnecessary.)

Answer 3

The team I work on uses 2-week sprints and for its presentation relies on internally-built as well as third-party UI framework components.

But those are usually for some "common" changes and features. Something new and top-notch cannot fit in a 2-week UX design period at all...

Answer 4

Aggressivley limit scope

The 2-week iteration has been grossly abused in the name of Agility®. Iterating on something in two weeks doesn't mean you have something ready for users in two weeks. It just means you completed a defined scope.

So the trick is, set yourself up for success. Carefully prepare for that iteration by selecting a piece of work that is completable.

If you're working in a space you don't understand well, you'll be counting on luck. If this is a space you know well, you might just be able to follow instinct to a killer solution.

Answer 5

Before my answer, let's just clarify: MVP is about sending a product to market really really quickly, in order to gather as much information about business benefits and user needs as possible, and using that information to change and improve the product in a series of rapid iterations. Yes?

If so, you will need two processes.

1: A long-term process that incorporates longer-term activities and artefacts. Call it a continuous improvement process.

2: A short-term process that covers that two-week cycle. Call it a sprint process.

Your sprint process will need (not a comprehensive list):

Input: existing artefacts e.g. user data; existing designs/branding; existing research

Activity: participate in daily scrums

Activity: identify (at a high level in sprint 1, then getting more sophisticated in subsequent sprints) users, goals, context of use

Activity: design low-fidelity prototype

Activity: test low-fidelity prototype

Activity: change low-fidelity prototype

Activity: mark up your low-fidelity prototype with metadata and unique identifier so it has traceability back to requirements and is useful for developers and testers

Output: UI design (your low-fidelity prototype)

Activity: analyse feedback from user testing, plan for next sprint, refine personas, user types, goals, scenarios etc

Output: personas, scenarios, user segments, goals etc

Activity: participate in backlog grooming

Ideally you should be working a sprint ahead, so that you have your designs ready and (guerilla) tested before they drop into the development sprint

If you've got the funding and the energy, you could have two teams each working in 2-week sprints but staggered a week apart, so that if your first round of user testing throws up issues, the other team could test your changes and feed back to you. That way you only have to schedule one lot of user testing per 2-week cycle.