In which phases of Software Development Life Cycle is UXD Involved [closed]

Question

I have a presentation about this topic, i would like to hear out from you about which phases involve UX activities.

It would be also appreciated if you could highlight what happens when we involve UX vs when we ignore it in those phases.

Thanks

Answer 1

I did not know what SDLC meant, so I googled it... it seems like a generic label for any project lifecycle.

1. REQUIREMENT

UXD is not only concerned with requirement gathering from internal stakeholders, but also from every single user that will be using the system on a daily basis. Not understanding their workflow, pains and needs risks designing a system based on the stakeholder’s vision only (which is usually a superficial and watered down understanding of what the system actually needs).

Not uncovering actual end-user needs at this stage will simply multiply the money spent fixing expensive decisions after development. Uncovering needs is cheap and focuses the project scope.

2. ANALYSIS

UXD employs many tactics to synthesize all the learnings gathered from requirements. It can find trends across both qualitative and quantitative data. This results in a clear vision of what the pain points are and a plan to move forward.

Without this the project can suffer from scope creep, meaning that every feature suggested by a stakeholder seems justifiable. Sooner or later, your project evolves into a Frankenstein of features with no clear purpose. This blows up cost, time and needless frustration.

3. DESIGN

Design with the users in mind. Design solving their main issues. Having a clear picture of who the user is, their pain points, will focus and streamline the design decisions taken. Everything that does not directly impact the issue at hand is automatically eliminated.

4. CODING

Programmers can work side by side with designers from Requirement, Analysis to Design. Being involved early and contributing to the project allows them to participate, give technical insight, be invested in the project and understand the needs of the user. This will result in better decisions made during coding.

5. TESTING

Testing in UXD can come at any stage of the project (basically whenever a gap in knowledge is identified and needed to be answered).

Testing before coding allows designers to make quick prototypes to test assumptions and different solutions without having to spend much capital.

Testing after coding, designers can make sure the system is working properly and continuously test and optimize it after deployment.

Testing is the core of user research. It’s very hard to design, make decisions and optimize a system without proper user feedback.

Without testing, teams are left with making decisions based on assumptions and biases. This is a waste of time because any decision taken is not based on real world data.

6. DEPLOYMENT

UXD testing comes in after deployment, like mentioned before. Continuously measuring, testing, analyzing behavior, how users use the system and tweaking to optimize, make new products, fixing issues. This is the effort cycle represented in the SDLC diagram, an agile rather than waterfall process.

---

There is a lot more detail that goes into it, but this gives a basic overview. Hope it helps.