Paint Managr
Project Parameters
Problem Space And Scope
This project is operating within the realm of the contracting construction industry, with particular regards to painting operations. Small businesses and independent contractors alike typically lack the resources or personnel to constantly manage material flows for different jobsites or the archival of all material quantities and costs for future job references. The aim of this design is to alleviate the struggle by providing an easy-to-operate system for recording and referencing the aforementioned data.
Project Management
For general contractors and project managers alike, rapidly evolving worksite conditions and last minute changes can disrupt even the most meticulously planned projects. The need to effortlessly track and reference used materials is therefore crucial.
Vendor Integration
Having to input material data repetitiously increases undue cognitive load. Integrating materials with the respective product databases of suppliers and the ability to remember and use prior manual inputs must make for a more efficient experience.
Before embarking on direct user interviews, I partitioned the problem space into several stakeholders and sub-problems. From there, identifying stakeholder roles and their corresponding needs allowed me to develop target functions to develop for. As for the sub-problems, each instantiation could be compared with others to see if a single potential sub-solution space might accommodate for more than one problem. All implementation would then fall under the umbrella of a "paint manager" service.
User Research
Interviewing
Having now targeted some potential problem spaces, I began to lay out interview questions for potential users. My initial line of questioning revolved around the sorts of problems that commonly arise in the sphere of project management. The questioning evolved into finding what sort of technical aides might be of help. I also pursued anecdotes that characterized some of these common obstacles in their day to day work. For privacy and security, I anonymized identities and sensitive informative as a condition of interviewing.
Analysis
After conducting multiple interviews with project managers and contractors in the field, I proceeded to the evaluation phase. Here I tweaked problem spaces, disregarded any flawed hypotheses, and began to shape the rough outline of the system. This was based around the most commonly experienced issues and wishes of the stakeholders. From here, early mockups could begin.
Wireframes
These are a few examples of wireframing mockups. They construct guidelines for functionality placement, navigation flow, and evaluation of information density. Most iteration to and from this point consisted of minor visual alterations, from layout adjustments to font hierarchy.
Hi-Fi Prototyping
A few screens from the polished prototyping. Some of the previously interviewed users were asked to evaluate some of the wireframes, which resulted in some alterations to menu flow and the placement of interactables. A lighthearted, easy to read color scheme was chosen for the hi-fidelity mockups.
Reflections
Repetitive User Testing
By engaging with the same stakeholders through both interviews and testing, I was able to accumulate far more precise data regarding features that needed drastic alteration or enhancement. When possible, utilizing the luxury of having repeat testers will be a priority going forward.
Strategic Interviewing
Recognizing that not everyone will approach problems from a designer's perspective was a stark realization I had during this process. In order to get at the sort of information I was hoping to collect, steering the discussions in certain directions was necessary. However, it is vital to extract their true opinions, not mine.
Back To My Work