Adopting UCD Methodology
When I was hired at my current company, they had never employed a UX professional. The software was typically designed by the architects and developers. The designs were inconsistent since different people were working on the applications. There were no shared libraries and icons were sometimes a large picture shrunk to 24 pixels. It would be a long road to gain adoption of any UCD methods.
To comply with my non-disclosure agreement, I have omitted any confidential information. The information in this case study is my own interpretation and does not necessarily reflect the views of my employer.
My Role
Originally, I was hired to bring some consistency to their current products and update the look to a modern aesthetic. They had 2 core products that were 30+ years old and enormous in functionality. They were both asset management applications and, on the surface, they did the same thing; however, under that seemingly similar surface they were very different.
Organization Chalenges
The first 4 months I was given demos of each product and their corresponding counterparts. The core products were once competitors and then purchased by a single company. Instead of choosing a single product and retiring the other, the choice was to keep both, and each product had their own team and they worked independently. Both products had a mobile offering that was built to accommodate those customers that had wanted to use the product on tablets or phones. One product chose to go the route of native while the other chose a browser-based solution. Even within the solutions there was not an agreement on execution and each product vehemently defended their choice as the right solution.
Overcoming Perceptions
My manager and I were both outside hires and we quickly discovered how both product teams perceived the other as a threat. The leadership of each team notoriously did not work well with the other so we would have to remove that obstacle. The idea of redesigning each of the products separately was not what the CEO wanted and the marching orders that was given would be to merge the 2 products into one common UI. This UI would allow the user to interact with a single experience irrespective to the core product it was connected to on the back end. A team was assembled for the first time from both product teams. The members were senior resources that included system architects, back-end developers, front-end developers, and a UX resource (me). As a team we would decide what technology to build it on and how to build this new application. The team would erode the negative perceptions of each product and allow for cross-product communication. We started with using the Design Thinking process and would later evolve it based on our team’s execution.
Workflows & User Stories
Each product team had their own process void of any user feedback, testing, personas, user stories, wireframes, pattern libraries, etc. This new product would need to employ UCD tools in order to show why they are so valuable and allow the other products to adopt them into their own process. We began this new product by engaging with Sales and Participant Services in order to understand how our clients used the products. I would spend a couple days listening to workflows and about our clients and I produced personas and workflow diagrams. This would be the first time the core products were ever mapped together to show differences and similarities. On the surface the products behaved identically to each other except for some additional functionality and terminology. After the workflows were approved, I educated the Sales and Participant Services resources on how to build user stories. We collected over 150 stories and from there 90 of those were chosen for the MVP.
Product Creation
In order to start developing the product with resources that were in 2 different locations, there was a need for a shared design library. Through some research I recommended that we use Material Design as the design pattern library. This was due to the decision of using Angular to build the product and the Material Design library had Angular components. This would allow me to put together prototypes using those patterns and the developers could quickly grab these components. The components would also all look the same no matter who was working on the view. This project was the first time that these developers were working off a designed prototype which was met with great excitement. They typically would get a scribble on a napkin or if they were lucky a product owner would use Balsamiq to put together a rough wireframe.
UCD Adoption
With some of these successes under my belt, I built a roadshow presentation that I would give to the other products teams throughout the company showing why UCD was so important. The company has a yearly event for their customers, and I even presented this roadshow in that forum. I also used this setting to get feedback on new designs/prototypes by customers that I typically did not get access to at any other time. The customers all were thrilled that they were being asked to be involved in product design decisions as this was only offered on a limited basis in the past. All the product teams now employ user stories in their Jira items and each product now has a list of personas. We still have work to be done around user testing as there are some obstacles to clear around data sharing/security. Below is the view of our UCD methodology.
Capture requirements, build personas, map workflows, identify product differences, and write user stories
Test workflows, validate user stories, conduct testing on supported browsers and devices, create documentation, and gather feedback from Beta users.
The Final Word
There was a lot of success in showing the value of employing UCD in product development; however, due to the complexity of the products each team would need their own UX resource to lead the endeavor. Currently I manage a small team and we don’t have the resources to proactively address the problems. We are still in a reactive mode where we are typically coming in after the feature has been developed which is costly. The company’s resources are limited in most disciplines which is an obstacle that creates a backlog of work longer than 6 months. This makes it difficult to get new features tested by users. Due to limited resources and the breath of products, the design/development process is more Waterfall than Agile. This makes it very difficult to have an iterative design process. The company has gone through a reorganization and has created a UX Department and has plans to expand the team in the future. I currently lead the team and advocate the inclusion of UCD via the UX team to all the product owners.