Simplifying collaboration

When Mirriad’s business started to change, the way the staff worked had to change too. The cumbersome software tools they used could not support the new ways of working. My task was to design a new software application that helped Mirriad staff work more efficiently and easily.

To comply with my NDA, some of the details I present are a reimagination of the actual design or design problem.

My Role

On this project I worked as a UX team of one, collaborating with the CTO, business stakeholders and developers.

The Challenge

Mirriad’s work is complex. But the software tools supporting this work needed to be as simple as possible.

Mirriad is a technology company that help businesses advertise in music videos and TV shows. It takes many hours of work, by several specialist teams working in tandem, to create the perfect advertisement for a client. The quality of the advertising is important, but the deadlines are even more so. The problem was that the existing software tools often caused mistakes and miscommunication, which leads to time lost, confusion and stress.

The software tools affected not only staff, but clients as well. Clients use the software to communicate their requirements, monitor progress, and measure the impact of the advertising.

A software application that is simple and easy to use, for both staff and clients, has a significant impact on Mirriad's success.

The Complexity

You can think of Mirriad as a big and complex factory. Raw materials get delivered to the factory warehouse, where they are sorted and prepared. Department 1 cut the raw materials into shapes and components ready to be made into products. Department 2 assemble the shapes and components. Department 3 paint the assembled products. Department 4 inspect the finished products for defects. Finally, department 5 packages and delivers the products to customers. And this is just the factory floor. We haven't mentioned customer services, sales and delivery departments.

But actually, Mirriad is even more complex than a factory. In factories, people are normally making the same products every day. But at Mirriad, what you make can be different every week or even every day. This is because there are many types of customers, each with their own unique requirements, which may change every week. So Mirriad is really a bespoke tailoring service, but at the scale of a factory.

The Research

People working at Mirriad had documented their workflows and methodologies, but the information was badly out-dated and incomplete. To understand the complexities of Mirriad, I interviewed my colleagues from all the departments to learn exactly what they did in their jobs, and how everything connected together.

Specifically, I asked people about:

• what they did

• how they did it

• when they had to do certain tasks

• communication within the department

• communication between departments

• pain points

• work arounds

• tools they used

• jargon they used

While interviewing my colleagues, I would sketch what we were discussing. I'd write down important concepts or objects, draw the steps involved in a process, and draw how things are connected to one another. This made it easier for us to communicate and think together, and helped prevent any misunderstandings.

With the offshore teams, research was more challenging, being limited to instant messaging and email. But there were advantages with text-based communication too. There was more time to absorb and reflect upon what people were saying, making it easier to follow up with good questions.

Mirriad staff conducted most of their communication with clients via email. My colleagues were happy to share their email threads with me, and this proved to be a rich source of information. The emails helped me better understand how people worked with the clients. I discovered important domain knowledge, problems, needs and goals - that were not always revealed in the interviews.

At Mirriad, people’s goals and motivations were highly related to their job role. Because of this, I decided to create personas based on their job roles.

Defining Requirements

To make sense of the huge amount of information I’d gathered in my interviews, I decided to perform a task analysis. The task analysis brought order and structure to the messy data I'd collected. And it allowed me to better understand the work people did at both a macro and micro level. Here is one of the many diagrams produced:

I wrote scenarios to imagine what an ideal situation could be like if people were using a better designed software application. Writing a scenario is like role playing on paper. You try to put yourself in someone else’s shoes, and go through the day as them. Scenarios let you see the difficulties people may be faced with, and help you imagine appropriate solutions. After writing the scenarios, I shared them with people to check for any incorrect assumptions or misunderstandings. This saved time because any mistakes could be corrected before the designs were created.

Wireframes and collaborative design

As soon as I finished the initial set of designs, I showed them to the CTO, who acted as the product owner. We did several design workshops together to discuss and refine the initial ideas. I used Balsamiq to create the wireframes, and this made it easy for us to make changes. After our workshops, we walked through the wireframes with business stakeholders and users in a story-telling fashion. The wireframes went through several feedback and redesign cycles until everyone's needs or concerns were addressed.

The results

The final design was very well received by both business stakeholders and users at Mirriad, and was approved for development. I provided the development team with a full set of annotated wireframes. To help them fully understand the design, I walked them through the underlying scenarios, use cases, and domain models.