Hi Brendin,
You have pointed out something really important and I totally understand how hard it is to have a concrete UX process. Truth is we should be able to change and adapt our UX process to match with the project and yes we will have to drop some of the techniques we are using and may be we will have to incorporate some new techniques to the UX process at each phase. I think that’s how it should be done.
Regarding your question, “How I approach tying everything withing the UX process with the team for mutual understanding and How do I communicate the progress to the team?”, I will take designing for a project as an example.
When we first get a project we have a list of requirements from the client which we have to deliver. In my case, the Project Manager come up with a project plan including following details at minimum:
- User stories
- Number of sprints
- Basic functionalities to cover at each sprint
I think no need to mention that one user story might cover a vast area and we might be able to break it down to several tasks. Once we have done our estimations within the deadlines and when the project plan is finalized we do kick off the project.
Tip 01: If possible, start the design sprint before the developers kick start the project
Right after you get the sign off for the expected deliverable for each sprint, start working on the first set of deliverable for the sprint 1.
Tip 02: Get the content finalized
Once you kick start with the design sprint before the developers and done your research, get the content finalized/ prove your assumptions to/from respective stakeholders and move into wire-framing. You will have to go back and forth with this until it’s finalized that is why you should start early as possible.
Tip 03: Get rid of the idea of perfection
As you may have already experienced, you cannot take one user story, finish it and then move to next. You will see many user stories as “in progress” if you are doing it right.
So you can finish off wire-frames for one user story and then move on to other and start wire-framing.
Tip 04: Try to get at least the wireframes finalized before the sprint kick off.
If you have wireframes finalized developers can start on back-end development for the particular story and you can complete the visual design on the fly and before the developers move in to front end development. Also, you might be able to move on to next sprint’s user stories and start wire-framing on them. This way you will be able to stay at least a sprint ahead than the developers and developers will always have a finalized design to work with.
In this approach you may notice that the S-5 model’s planes are really overlapping as they should according to the best practices.
How do I communicate with the progress to the team?
1. Daily stand ups
I communicate my progress, what I am currently working on and also if there are any issues or blockers . So that everyone knows what’s going on and they can plan their work accordingly.
2. Have a place to share your work.
You can use a Skype group to keep your team updated with your progress, design decisions and any changes that will be done apart from the initial path. For some of those decisions you may need help / comment from the developers / Project manager. By using such a space for communication, others can easily reply and also you can have a track record of decisions you have made.
Apart from the decisions, to share your delieverables of the project, there are few options.
1. Google drive
You can put all your finalized work in a folder and share it with the team
2. Adobe XD design spec
If you are designing in Adobe XD, you can publish the design spec and share the link. If you are doing any changes afterwords, you can save and update the link.
3. Balsamiq cloud
This is for wireframes. You can share it with the team so they can look at the wireframes and give their comments or start working on them.
These are the options which I personally use but there are some other options too.
3. Keep up with the communication
If you are communicating with your client / any other significant stakeholder make sure other parties who need to know those decisions are also copied in.
For an example : If you are changing something about a requirement, the development team and also the QA team should know about it. If it’s an e-mail, make sure to CC the respective leads so they will guide their teams.
4. Participate in Demonstrations
Demo is a good place to show what you have done and also compare it with what’s been implemented. It can be an internal demo or an external one where your client is also participated.
Those are the steps which I normally follow to keep the communication with the team.
Key point is to always get involved and get others involved too, so everyone will be on the same page.
Also, I think a UX wall is a good idea too, so anyone can have a look and get an idea about your progress. I think if you can do it while following the above steps, it will be really great because then, anyone who haven’t been to all the meetings and demos but have heard from here and there, will be able to come to UX wall and get the missing information. :)
I hope I have helped. This indeed can be a topic for another article.
