CASE STUDY: CLOUD 9 INTERCOM
Cloud9 Technologies is a company that specializes in communications software for financial firms. Our team was tasked with creating a desktop application based on a trader’s turret. The final deliverable was a functional prototype that the client would later use to built the app.
EXPLORING THE ECONOMY OF ATTENTION AND SPACE
Traders are a very specific type of user. They need to be able to make contact quickly and efficiently.
The application needed to blend in seamlessly with their current workflow. It should not add steps or complexity.
The application also needed to be mindful of the economy of space on the users’ computer screens: when does it need to take someone’s attention? When does it need to play a more passive role?
Product Designer, Engineer
Project completed in 2016.
We began by interviewing key stakeholders and traders. We learned about their work habits, how they like to communicate with clients and colleagues, what other types of communication tools they use for work and personal.
The application was designed in 3 phases. In Phase 1 the app would be able to handle internal voice calls. Phase 2, it would be able to make external voice calls and handle interoffice communications. Finally in Phase 3 it would handle text messaging. Working in Phases allowed us be focused on each feature while keeping the roadmap in mind. This also helped to keep us on track for our 3-month project timeline.
We started each phase by brainstorming and sketching all possible features that could be implemented. The strongest ideas would be expanded upon by white-boarding user flows and wireframes. From there, the engineer would begin laying out the structure of the build, while I begin to design the features. We prioritized which features made more sense to tackle first, sometimes the more complex elements and sometimes the lower hanging fruits.
By midweek we’d have a loosely built prototype that we can test our assumptions. Revisions would be made, whether it be a button that needed more contrast, typography that needed to be more legible, or re-working entire flows to make it more intuitive.
At week’s end, we’d have a check-in with stakeholders to present the features that were implemented. We’d gather feedback and note any revisions that needed to be made. All that would be noted for our starting point for the next week in addition to new features to be tackled.
It was a highly collaborative team and often we found our roles to overlap each others in harmony. Working so closely with my teammates and observing the collaboration that happened really surprised me. It was incredible to see individuals bringing their expertise to the table, sharing openly, and being respectful of everyone else’s ideas. This experience taught me to seek out team members early on in projects to learn what they think would be a better way to improve the product.