The Company
ACS Technologies is a church management and social engagement software company. ACST software is used by more than 50,000 churches and nonprofits around the world. ACST software enables organizations to manage finances, communication, events, and other areas.
The Product
“Messages” is the project name for a web based, instant messaging tool. Messages allows users to synchronously or asynchronously communicate with their friends, groups, and group leaders.
My Role
I worked at ACST from October 2013 to October 2015 as a UX / UI Designer. I was the lead designer for Messages. I worked in a team of a product owner, fellow UX designers and lead UX designer, and front-end and back-end developers. I led the design of Messages from ideation to high-fidelity mockups.
The Goal
ACST needed an instant messaging tool that kept up with conventions of similar apps and worked well on both desktop and mobile. Messages would need to integrate with other features in the forthcoming web app.
The Challenges
- The team and I had would have to avoid design creep. Team members had wildly different ideas of what Messages should be.
- Selling the concept to apprehensive stakeholders within the company would be difficult. Instant messaging was a novel feature for a company.
- There were few mechanisms in place for conducting UX research. User empathy mainly came from the teams' personal experience, domain knowledge, and market trends. The design process was driven more by iteration and UI fine-tuning than by research.
The Design Process
My product owner and I kicked off the project with an informal chat. I wrote down a list of requirements in Evernote.
I examined other instant messaging services to pinpoint patterns and conventions. I then set to sketching interfaces on paper. I showed my PO some initial thoughts, and we bounced ideas off each other frequently. I met with a developer to go over constraints and get his thoughts on some initial design ideas. I performed some guerrilla user research by visiting area churches and discussing their communication needs and habits.
I then began designing in Sketch. I created a couple dozen wireframes and posted them to Invision for feedback. Other UX designers and my PO commented on the designs. I iterated accordingly. Here are my earliest designs:
I presented the designs to the company stakeholders and their reaction was not positive. They had a difficult time understanding the business need for Messages, and they felt the proposed functionality was needlessly complex. They were right. The designs had interesting features, but they felt extraneous without research to support the need.
The Scenarios
I accepted their feedback and went back to the drawing board. The problem, I realized, was that the user scenarios were not well defined or accepted. A user scenario could help demonstrate the business need for Messages as well as promote empathy among the stakeholders.
I went back to my PO and UX lead and we agreed upon three core scenarios. I reworked my wireframes to address those scenarios. I zeroed in on core functionality and ripped out anything that was not essential. I presented the revised wireframes and new scenarios to the stakeholders a second time. The reaction was very positive. Stakeholders were much more interested and agreeable. They approved the designs for development.
The Final Designs
I polished the UI for the designs and added red-lines and specs for the developers to follow. This was my last major project for ACST, and I wanted to ensure the designs were implemented correctly in my absence.
Lessons Learned
User scenarios are key. Define them at the beginning of the design process and then refer to them throughout the process, especially when sharing or selling the designs
Focus. Referring to user scenarios forces the designer to consider only the most essential features of the design.
Polish the UI and leave nothing to interpretation. I learned a great deal about UI in this project, including color, information design, and feedback