The SocialChorus admin platform was a tool that clients could use to manage, optimize, and evaluate their employee news reader platform. So in a sense, it’s a platform behind a platform. It contained a wide variety of functionality that was built up over the years. For example, an administrator can see analytics, post content, manage user accounts or change the look and feel of their news reader.

This platform underwent many different revisions as the company pivoted. Over time, it focused less on social media sharing and contests and more on content creation and targeted notifications.

From the years of 2013 to 2016, I was a user interface designer of the San Francisco-based software company SocialChorus. Originally, their software was focused on brand advocacy. However, it ultimately pivoted to create an internal newsreader for employee communication. With this software, employees of companies such as Ford and Whirlpool can keep up to date with information about their workplace.

One of the major things I learned during my time at SocialChorus was how to design user interfaces in an organizational setting. So not just designing for an optimal user experience, but also designing for different stakeholders in the company. Though it may be unintuitive to think about, the actual users of the SocialChorus platform were not the only audience for my designs. The challenging part is ensuring that the priorities of the users and the stakeholders can be both met and are not mutually exclusive.

For example, SocialChorus’ clients often have different people looking to buy the software as opposed to those actively managing the admin platform. This creates an interesting point of difference where the buyers are looking for the presence of features. They would like to see a visually-polished interface and are looking for specific features that they can compare with other similar platforms like password protection or notifications. Often, I would be asked to design a mockup that would be extremely far advanced in our development cycle in order to showcase new functionality. To them, the design was a dream of what they could have.

Conversely, the active managers of the platform would rather see the current interface that they would be working with and understand how the platform will aid them in creating a company news reader. Rather than seeing new features as a selling point, they see them as another thing they have to learn in order to do their job more effectively. So having an intuitive interface that is similar to what they are used to was fairly important to them. To them, the design was a work tool.

Lastly, the in-house software engineering team was also a particular audience I had to design for. What they were looking for was specifications everything they might have to code within the system. What was extremely important as a UI designer was that I could visually present examples of every single outcome that could happen to a user. For example, what will happen if a user tries to input an emoji in a post title? What will happen if they try to fill out a form without filling everything in? To them, the design was a blueprint for every possibility.

One aspect that I found interesting in the design process was that the engineering department practiced elements of “extreme programming” and “agile development.” Instead of following a strict, long-term plan for product development, SocialChorus’ software would make many incremental improvements over time and adjust along the way. The advantage of this system was that our product could be as flexible as possible.

What customers want often changes and it would be disadvantageous to stick to an obsolete plan of what the product should be. Therefore, the features of the software were broken down into their smallest, shippable elements which bode well with the philosophy of “minimum viable product.” Once a feature was created, it’s added to the software and the software developers move on to the next feature. This allows customers to get high priority features quickly instead of altogether when it might be too late.

Because of this, crafting a holistic experience was difficult to do considering the number of on-the-fly changes. It was much more practical to be concerned with immediate product development. However, this also has the side effect of being unable to control how well these features work as a whole. Say a button UI style is used for one feature but doesn’t work well for another. Should a designer use the same style so it’s consistent for the user? Or should the designer use a more appropriate style, running the risk of confusing the user?

Another unfortunate aspect of this process method is that it’s challenging to have a sense of completion when creating a design. Often, when a design is released, it is in its most bare-bones form, possibly lacking functionality or visual styling. After then parts get added on, some right away and some months down the line. While it does make sense for a company, as a designer I never really had a sense of pride and accomplishment knowing the product that people use is not a polished, robust experience as it could be.