-1

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

closed as too broad by locationunknown, Michael Lai Oct 19 '18 at 6:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • User experience design is a process or methodology that can be applied in all stages of the software development lifecycle. It is not always appropriate to apply UXD in software development, and you can apply UXD in areas outside of IT as well. – Michael Lai Oct 13 '18 at 9:25
  • Who is the audience for your presentation? Can you add a diagram to your question that shows the software development lifecycle you’re using? – Michael Hogan Oct 13 '18 at 17:55
  • I had some thoughts and graphics on this question but UXLabs has changed it? The question was about what UXD is in relation to SDLC. It's been changed to what parts of SDLC "involve UX activities"? The part of the question about using SDLC in UXD has been deleted? The question about not using UXD in SDLC has been deleted? The edit adds a new, different question asking what happens when you ignore certain phases of SDLC. – moot Oct 15 '18 at 9:59
3

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.

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

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

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

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

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.