The Ask: Design and develop a project management console that unites the three practices within Credera: Management Consulting, Technology, and User Experience
The Solution: A platform built with AngularJS, Play/Java, and MySQL that allows all members of a team to communicate and collaborate with one another in a streamlined and efficient manner
The Client: Credera
The Class: Senior Design
The Program: SMU Bachelor of Science in Computer Science
The Timeline: October '16 - May '17
For our senior design project, Credera came to us looking for help in designing and building a web based project management console for their consulting practice. Between the three practices of Management Consulting, Technology, and User Experience there was an apparent disconnect and communication breakdown. When different members of the departments were put on a team together to solve a problem, there was not a great way for them to easily convey ideas and communicate between each other. Sure, there were other communication tools out there such as JIRA, trello, and InVision but no platform that has them all combined together.
Our product is a mix of all of the best features of those technologies rolled into one package. We offer a platform that allows users to upload wireframes, enter tasks/business requirements, and then map the various requirements to individual wireframes. This association between tasks and wireframes is the most notable part of our app. In this way there is an easy way for management consultants to see that their requirements are getting fulfilled by the wireframes produced by the design team and the webpages developed by the tech team. We hope that Credera will use this application in house and potentially deploy it as a solution for their own clients.
For the seven months we were on this project, we followed a Scrum methodology with an Agile attitude (to see why I don't say Agile/Scrum read from one of my professors here). After an initial client discovery phase, we went through a number of sprints to design, develop, and test our application, eventually deploying to Google Cloud and delivering our finished work to the client.
For the first phase of the project we conducted a series of meetings with the Credera team to understand what their needs were for this project. We heard from them about the need for a new project management application that they needed for their business. When management consultants at Credera would work with a client to understand their business needs, they would create a long list of requirements to hand off to the technology and design teams. The designers then created a series of wireframes and the tech team built out the application off of those wireframes. However, often there would be miscommunications between the three practices that would lead to duplicated work, designs that did not fufill the requirements, and pointless code. Countless hours are lost on every project due to these miscommunications. The biggest need they had for the application was a way for designers to illustrate what business requirements their wireframes were satisfying, so that the team could catch any errors early, before they had negative imapct. While this was the most pressing part of the problem, the application would also need the usual trappings of a project management console such as user accounts, projects, et cetera.
In these initial meetings Credera agreed that we could select whatever technology stack we needed to complete the project, but indicated that they would have limited time to provide technical mentorship during the project. We were expected to design and implement the project on our own, only receiving feedback during scheduled design and code reviews by Credera. In the first month of meetings we decided to develop the project using React, postgreSQL, and Scala, all technologies we were unfamiliar with but wanted to learn. We also created a portfolio of rough hand-drawn wireframes which we tweaked over the process of a few meetings to better serve the client. These wireframes and tech stack gave us what we needed to start production of the project.
By the time we were ready to start development we had about a month until Christmas break. We took that time to familiarize ourselves with the new technologies we endeavoured to master by creating test projects and walking through online tutorials. By the time we got to Christmas, our team was having doubts about all choosing technologies we were unfamiliar with. While it sounded fun to try to learn new tech, we all found it difficult to devote the time it was going to take to implement this project with totally new programming paradigms (as was the case with the functional language, Scala). Coming back from the break, we all sat down and had an honest talk with one another about the success of our efforts and our progress to date. We dissatisfied with the way the project had gone thus far and decided that pivoting to languages we had more experience in would make sense, as we only had a little over three months at that point to complete the entire project. After all, there was still plenty to learn even with the technologies we had used before. After meeting with Credera and breaking down our thoughts, they agreed to our technical decisions and supported us in transferring platforms. The decision paid off. Even though we had to start from scratch on the project, we were able to work much more quickly with the new tech stack. This stack consisted of AngularJS (with bootstrap), Java (with Play framework), and MySQL.
Once we decided to make the switch, we were able to start down a series of sprints designing, developing, and testing our product. For each two-week sprint, we would sit down, create a higher-fidelity wireframe, breakdown all of the tasks associated with producing that frame, and then execute those tasks in code over the next two weeks. Even though we were using a Scrum model, we kept a flat hierarchy and each made sure to divide tasks fairly between the four members of the team, staying in contact over the duration of the sprint. At the close of the sprint, we performed unit tests using JUnit and Karma, and integration testing of various components. We stayed in close contact with the client to ensure that each sprint was getting closer to the final vision of the product. Over the next three months we were able to build out the features needed to make this a solid web application, eventually deploying to Google Cloud, and delivering the code through a shared GitLab repository.
We were proud of the product we were able to build over the course of the project, and Credera was satisfied with our results. The final product consisted mainly of four main views: project view, design view, requirements view, and detail view. The project view allows a user to see which projects they are a part of, and to create a new project if necessary. Clicking on a project takes the user to the requirements view, which lists all of the requirements that the project must fulfill. Each one of these requirements is arranged in one of four columns: To Do, In Progress, In Review, and Completed. The user also has the ability to add or take away columns as well as change the names of each column. Each requirement can also be edited in name and description. Next is the design view, which displays all of the wireframes uploaded for the project. Each of these can be edited as well by changing the title or uploading a new image. Uploading a new image just updates the wireframe but keeps all data associated with the original wireframe. Lastly, representing the crux of the project, is the detail view. Clicking on a particular design takes a user to a screen that displays the wireframe image in the center of the screen with a scrolling pane of requirements on the left hand side of the screen. This pane has requirements sorted by Assigned, Unassigned, and All. The user can select the appropriate category to see which requirements are fulfilled by this particular wireframe, which requirements are still unassigned to a wireframe, and all requirements for the project. Clicking "Assign" on a requirment allows the user to draw a selection marquee on a specific part of the wireframe. Through this screen, a UX designer can indicate which of the given business requirements are satisfied by the wireframe he/she developed. All team members can then see what activity is going on and catch any errors early on in the process, instead of each practice being siloed for the project. There still remain many features we would love to develop if more time was allowed, such as an internal chat/commenting feature where users can agree/disagree with associations between requirments and wireframes, and the ability to upload InVision-style clickable prototypes instead of static wireframes. We hope that this project continues to have impact within the Credera organization.
RefillWise Price Transparency ToolUX Research | HCD | App Development
Where's My Card?UX Design | App Development | Digital Marketing
Dell IoT ApplicationApp Development
Credera Management ConsoleUX Design | App Development
Accenture Innovation StrategyDesign Strategy | UX Research
SPCA Loose Dog ProjectUX Research | Human Centered Design
The Happiest HourUX Design
Visual Design CompilationVisual Design
Titania LampIndustrial Design