Over the last couple of years UCD (User Centered Design) has become a buzz word just like RWD (Responsive Web Design). 5 years ago when I wrote my SharePoint Branding book I use to call it the 4D’s of User experience. It included Discovery, Definition, Design, and Development. I had a nice little picture and everything to depict the different phases.
Now the picture is much nicer and clean however, I really don’t think it matters what you call each phase it matters more what you do within them. I have seen so many different variations sliced and diced in different ways. To me it is about adjusting your approach based on the needs of your users and your client. In a more traditional waterfall project you have a tendency to over burden yourself with documentation because there is no chance of going back. Also those types of project are usually the ones where you scope out in the begging a full solution without ever fully knowing what the real need actually is. I would much rather only scope the first couple of phases to really truly understand what you are dealing with before you can even imagine what the technical effort would be.
The biggest shift that I have seen though a more refined UCD approach is really focusing on the first phase which is understanding who the users are, and what are their needs. This is a shift in getting away from just focusing on Functional Requirements but diving deeper and truly understanding individual user needs. In the past I used to focus on how to customize and configure a tool like SharePoint to give the users a somewhat tailored experience. This did not always provide the users what they needed but it was better than nothing. I do have to say it is really refreshing being able to go into a project technology agnostic. To me it sometimes feels like you are trying to put a square peg in a round hole if a technology has already been defined by IT and there is no clear use case or need from the users on how they will use it. This is a clear case where user adoption will become an issue and it will be a big waste of time and money.
One other shift I have noticed over the last few years is that personas have really changed their meaning and purpose. We use to define different personas based on their organizational structure (HR, IT, Sales) or by their permission roles (Admin, Contributor, Reader). We also use to focus more on their demographical information such as (Age, Location, Device Types) which really did not provide much value.
I think due to the fact that I spend more time diving deep through user interviews to gather as much as I can about their day to day activities. Learning more about what their pain points are and identifying commonalities with all that we have met with. This helps drive better insights into who those core personas will be and not just based on a title or a role. These types of personas will help us during the definition phase when we start to translate their user needs on to paper.
Not every project needs to have a full set of polished personas, but at least some level of understanding who you are designing the application for. For the most part the 4D’s still hold up pretty well but like I said before it really does not matter what you call each phase so long as you are providing value in each one of them.