This is a UX project to redesign the interface of an internal project management system used by agile software developers
My first act was to speak to the scrum masters and members of their teams to see how they used the current software and what they would like improved. Much harder was to try to find what could be removed. The old system had every idea that had been thought of stuck on it somewhere and most weren't useful and hadn't been removed.
I worked with one team offline to see how they would manage the project outside of the confines of the computer system to help me learn more about their process. I wanted to find the minimum that I could include and make the software intuitive. A lot of complaints of the current system are the lack of intuition and the lack of usability, I noticed that the whole company used Microsoft Outlook as a company standard so I wanted to use aspects of that interface and usability in this project
I started by creating wire frames of a new fronted with the restriction of running it on the same backend. Based on the simplest functionality needed to manage a projects. The biggest problem the users faced was changing between two screens depending on wether they were editing, creating or deleting a task. I started by creating a wireframe of the simplest way this could work together.
After showing the wireframe to some people I realised that a lot of feature team leaders worked in very different ways and had requested lots of functionality but at the same time the other users had a complex tool that didn't really support the way they needed to work.
I kept the original pages live while creating the new version. So people could move over when they felt comfortable with the new look. This meant I could start getting much more tangible feedback right away. And the whole application was a kind of A/B testing scenario so I'd know when a page was of more value than the original.
Working in iterations of about two weeks, I was adding around three features at a time. Because it was all internal I would send out an email each iteration letting the users know what new features had been added or removed, what they should expect in the next iteration and asking for votes on future development.
I created a suggestions page where people could 'like' each others suggestions. The number of likes was then divided by the time it would take to design and build and gave me a good indication of what was the best use of my time.
Collecting all the feedback was perfect and the work I did as a result worked really well. I overlooked a couple of important things with this project. One is that with a small user base the collecting and implementing of information can be just as much about building trust with the users as it is about gaining the actual information. The other is that making to drastic a change in the first iteration can make people reluctant to ever accept the changes and buy into the new tool. A gradual improvement from the old tool would have taken more time but ultimately been more value to the users.