Womply Messenger
Messaging for small business
At Womply we provided small business owners tools to better manage their work. Much of the product work I did included using credit card data to show where else, and how often their customers were spending money, so they can better manage their resources, like scheduling, stocking, online reputation, and advertising.
The kinds of businesses our products focused on were primarily retail, and restaurants – the kind you might look up on Yelp before hand. We had a relationship with the small businesses which gave us a familiarity with their pain points, and one problem we wanted to tackle was communication between employees.
But why you might ask?
What we understood about this population is that there tends to be high turnover. Many of the employees working in restaurants, and retail, work part time. We also knew they had cellphones (who doesn’t). They might also be in school, or even have several jobs. These are people on their feet, often in busy settings while on the job.
So couldn’t they just text?
Well yes, they could, but then the problem you run into is one of privacy. You have to save a bunch of phone numbers of co-workers every time someone new joins the team. You might not need, or want all those contacts on your phone, and what happens when someone quits? Do you delete their number? If you don’t, you could end up with contacts on your phone you may never hear from again. But what if they don’t delete your number, do you want an ex-coworker calling or texting you willy nilly?
Okay, I get it, I don’t want my ex-coworkers and ex-bosses having my phone number. But why not just use Slack?
Slack is great, and definitely something we looked at during our competitive analysis. Slack works really well for big teams, where you need multiple channels, groups, and integrations. Slack is great for offices and desks. However, there’s a lot in there for someone working second shift at the bakery who needs to check their schedule, or wants to check stock in the back room, or someone working register, with a line in need of $20 bills and quarters. You need a quick way to communicate with someone some where else on the floor.
Other apps we looked at during our competitive analysis included WeChat, WhatsApp, Hangouts, KakaoTalk, Line, Skype, Facebook Messenger, Crew, Kik, and a few others. While there are great things about those apps, they tend to skew more social, revolving around friends and family. We were making something more streamlined, more professional, and designed for the workforce. We didn’t need all the stickers.
Enter Womply Messenger
Our primary goals included empowering a high volume workforce by improving team communication on and off shift. We chose to solve this problem with a no-frills chat app which prioritized transparency, fast communication, and teamwork. We wanted to create something that was as simple as texting without having to save any contacts to your phone.
So where did we start?
With the minimum viable product there were several specific areas we wanted to focus on.
On-boarding
Inviting other coworkers
The main chat experience
Take 1
The first time I designed this experience, I added all these on-boarding screens, but during feedback sessions, I heard people would just swipe through them – no one was reading them. Did we even need these screens, what value do they add? So I killed them and revised it all down one screen.
Take 2!
Instead of listing out all the things you can do with the app on 3 different screens, we revised the messaging to read simply: "Join your coworkers and get to work", and changed to tone of the button to "Let's go"; language with a little more energy.
But where's the log in, and password field?
One of the goals of this app was to eliminate the need for passwords. Your phone number is your log in, and we send an SMS code for verification instead of using a password – there's nothing to memorize.
But what if I enter the wrong phone number, or don't get an SMS code?
Well, we try to catch it first with a confirmation screen, but if you miss that, simple: hit back. Once you enter credentials we tie the phone number to a user in the database. We require a valid email address, but you can use the app without immediate verification. We designed a code called a "Magic Code" which is like an invite to make sure you're joining the right business.
Here's the entire on-boarding flow.
On the left is a click through prototype I made using Sketch, and Balsamiq.
On the right is an early version of the app running on android.
Well, now that I'm in, I need to invite others so I have someone to talk to.
The next step in this journey was to design the experience for inviting a coworker into the app.
I started designing the experience with a decision flow diagram to account for the various ways someone can get into the app. It started with the question can I invite someone who isn't already in my contacts list.
Once we identified the main pathways, I started prototyping. I created the screens for the invite, flow and put together something we could click through on a phone.
Alright, I'm in, now let's chat!
In this early prototype of the UI (made with principle), I focused on the read receipts, and how those receipts might be handled if they failed. I partnered with an engineer to make sure I was accounting for as many fail cases that we could think of. I've learned that engineers are pretty good about anticipating how things go wrong – I keep them close.
During design feedback sessions, I was hearing that my initial bubble UI looked heavy, and might be distracting. Do we need the bubbles? Are they adding value visually? Does the UI work without them? I took the feedback, stripped out the clutter, and ended up with an interface that is much easier to read. Yeah, actually it looks beautiful without the bubbles.
So how do I know anyone has seen my message?
Transparency was a priority of the experience, we wanted to ensure people knew they were being heard. In a busy work day messages can get lost; if a message is important enough, we wanted to give people a way to double check that coworkers have seen it. As we brainstormed, and researched ways make this happen, we chose to explore read receipts. I looked at a few other apps to see how they handled read receipts, and created some prototypes to feel out the interaction, and timing. We used single, double, and closed check marks to convey delivered, seen, and seen by all (if in a group) respectively. A tap-and-hold interaction shows who's seen the message, up to 5 people. After 5, we truncated it to "seen by 6 people", we made this choice primarily based on screen real-estate.
What's next?
After we launched the minimum viable product, we started collecting data on how people were using the app. Did it meet our goals? Did it improve transparency, fast communication, and teamwork? One problem we noticed was one of stickiness; were people using the app throughout the day vs. periodic check ins? We found that most people used the app occasionally, and not throughout the day. One hypothesis we had was that, if people were on the move all day, they might not be able to respond to every message, nor should they feel obligated to. But they might want to participate in the conversation without sending a full response.
How might we keep the conversation flowing, without requiring people to type out a response to every message?
To answer this question we developed a feature we called quick actions.
I started designing this feature in low fidelity, then created a lo-fi click through prototype. Once we felt like we were happy with the solution, I moved into high fidelity. I created a few versions to experiment with the interaction, the menu, feedback, and how the quick action icons played into the chat timeline.
In the first iteration, I made a pop out menu. The quick action icons threaded, so they all appeared below the corresponding message. During feedback sessions, it became clear to me that this approach had a flaw: the screen could quickly fill up with a row of threaded responses. I scrapped that idea, and flowed the icons in-line below the message. Tapping the icon would show who sent it. This approach made the conversation flow much more naturally.
Just because people may not have time to fully participate in the conversation, doesn’t mean they don’t want to. We tried to give co-workers tools to facilitate conversation throughout the shift, and tried to include features that allowed everyone to be heard, know their message was received, and participate in the dialogue even if they only had a moment to check in.
What were some of the challenges?
One of the challenges of designing this app came from building it for both iOS, and Android at the same time. We had 1 iOS engineer, and a remote Android engineering team of about 3. We built for both platforms simultaneously, which meant I had to become very familiar with iOS guidelines, and Google Material guidelines. I was delivering design assets for both. I got around this challenge by developing a design system that worked well on both platforms. Occasionally I’d have to make adjustments to accommodate a specific native Android or iOS interaction. By creating a reliable system, I could focus on the user experience, and develop the visual user interface relatively quickly. We held regular design feedback sessions, and I ran everything by the engineers to make sure the hand-off would be as smooth as possible. Sometimes I’d miss details on one platform, and sometimes I’d get an interaction wrong, but with frequent check-ins our engineers would let me know when I made and oversight, and I’d do my best to provide the correct asset in a timely manner. The solution to the problem we set out to solve became the foundation of our team – clear, and transparent communication.
Additional Works from Womply
Card Transactions
Creating a way for merchants to track incoming revenue
Card Transactions is a popular feature in the Merchant Insights application. It allows people to view individual, incoming credit, and debit card transactions, while providing transparency, and accuracy to the other revenue focused applications. It correlates closely with the Revenue Graphs, since credit card transactions provide one of the data points that populates many of the insights features.
Earlier versions were read only, and had little engagement value, without a method for sorting or finding specific transactions. With a tight 1-week deadline, I put together a small team of 3 – including another UX designer, and Product Manager, and we set out to solve this engagement problem, including improving overall usability.
Objectives:
Display my transactions.
Increase engagement by encouraging interaction through sorting, filtering, comments, and starring.
Provide relevant data about my transactions, and make it easy to find specific transactions
Narrow down my results so I can find specific transactions
PROCESS
We each did competitive research and focused on looking at specific features, and tasks, and created a SWOT analysis to summarize our findings. We looked specifically at filtering, and displaying interactive tabular data.
After reviewed details/findings from our research, we put the objectives on the wall and narrowed down a list of features to focus on when moving on to sketching.
We worked in design “sprints” and blocked off 5 hours to sketch, and review solutions, limiting ourselves to 30 minute intervals per solution while ideating.
Working independently in the same setting, we set the goal to produce 5 sketch solutions. At the end of the hour, we each ended up with 4 sketches.
For the next block, we put our sketches on the wall for review. We chose the most successful solutions, iterated on them, and narrowed our sketches to 3 options. At this point we checked in with the product manager for feedback.
After a discussion about each option, we chose the one we believed to be the most successful and began wire framing the experience. I took sketches into balsamiq and developed click-through prototypes. We tested the prototypes for usability, collected feedback and refined the wireframes before moving into code.
We learned from testing that our first attempt at filtering wasn't intuitive, so as we iterated, we refined the filtering options, and filtering UI. Another concept we introduced was tagging, which turned out to be confusing, and unclear, especially beside comments, so we dropped it as we moved forward.
To reduce engineering complexity for the minimum viable product, the Product Manager chose to drop starring, and comments. This decision allowed us to ship the feature quickly, and gain analytics from a wider user base.
I worked closely with the engineers to come up with a mobile solution. Data tables for mobile can be particularly challenging, since they don't shrink down quite as nice as block column layout. The first approach I considered was a table with a max-width, and an inner scroll; the user would scroll left to right to see all the fields in table. None of us were very happy with this solution. One of the engineers had the idea of displaying the table as a list, and labeling each field vertically. This solution allowed all the data to be presented, and naturally scrollable. I put together some quick wireframes to get a feel for layout, and we moved forward into code.
Insights Revenue Graphs
The Merchant Insights' revenue graphs are one of the most popular features of the application. The revenue graphs allow merchants to see incoming revenue trends; though due to the complexity of previous version, engagement was low. The previous version of the revenue graph had 36 views that the merchant could select from. The problem was that the selection controls were complex and could be difficult to understand.
Based on analytics, and merchant feedback we knew the highest engagement was related to Revenue, Revenue Comparison, and Day of Week. With this in mind, I collaborated with product management, and the engineering team to redesign the graph experience from the ground up. We simplified the design, separated the graphs into 3 focused experiences, and surfaced the date range selection control allowing for custom date selection which was previously unavailable.
PROCESS:
Along with the Product Manager and company founder, we collectively defined goals and objectives, and I began with low fidelity pencil sketches. When we were comfortable we were heading in the right direction, I created a limited number of hi-fidelity variations to collect feedback. Using the UI animation tool Principle, I developed prototypes to test usability, illustrate intent, and gain feedback on engineering complexity. The PM and I worked closely with the engineering team to incorporate feedback and come up with a successful approach to develop the graphs into a live interactive feature.
TEMPLATES :
Since we had several graphs that relied on the same visual language, I developed a series of templates to illustrate how the data connects to the visual language. As an additional guide, I included annotations to indicate spacing, intention, and typography.