Thomas Pritchard

Product Designer

Brand Amper (Case Study)

Brand Amper is an enterprise brand communication platform that captures employee stories for use in recruiting and marketing.

They came to DeveloperTown looking to design and develop a platform that would enable clients to understand and integrate their employees’ brands into their own recruitment and marketing efforts. They also wanted to measure and report key metrics to those responsible for the company's employee brand in order to demonstrate just how important it is with hiring and retaining employees.

I was responsible for designing a web interface that a Human Resources department would use to configure, manage, and measure the success of the employee-facing tools Brand Amper provide.

User Research & Personas

In order to understand the problem domain and design a cohesive, valuable product, I spoke extensively over a number of days with the team at Brand Amper, about who would be using this tool, and what their needs and worries were. From our discussions, two key personas emerged who would be important stakeholders in the management and feedback interface.

The first persona is Katie. Katie is the Community Manager at ACME Inc, and is directly responsible for managing the employee brand, and reports directly to the Chief Human Resources Officer. She is having trouble convincing employees to work through the company’s existing personal branding exercises, and those that have completed it have not stuck with it. Little sustained success, coupled with increasing time and budget pressures, is making her job more and more difficult.

The second persona is Alana, the Chief Human Resources Officer at ACME Inc, and the person ultimately responsible for all of the work in the Human Resources department. At the moment she can't draw a direct line between the actions her department makes and the positive results that are felt around the company, and as a result she is finding it difficult to obtain the funding her team needs. Alana needs a clear and easy way to communicate with her other C-Level peers, and also the CEO, the value that her team brings to the company. The value of the knowledge of the employees’ brand is an important part of that.

Strategy & Recommendations

After User Research, it was important to develop a set of strategies and recommendations for the product moving forward. We needed to develop goals that reflected the needs of the existing processes, and alleviated the pain points currently being felt by the users. These goals were referred back to each time I conducted user-testing, in order to make sure the product was moving in a direction that was still in the users' best interests.

The criteria laid out in this step were design recommendations that brought together the user research and the strengths and positives of existing solutions to form the building blocks of the initial concepts of the application.

  • The application must be able to report clear success statistics to demonstrate the value that the employee branding initiatives provide to the company. The existing solutions do not provide the department with any relevant information about the company's employee brand. An improved solution would provide the clients with actionable data which provides value throughout the organization. For instance, a good understanding of the employees' personal feelings around the company's brand could be used to help recruit candidates which are most aligned with the company’s most successful employees.
  • The application will be used by time and labour constrained users, so the application must be low-maintenance and quick and easy to set up and become familiar with.
  • The application interface must be flexible enough for a company to run a 50-person initial trial study, and also able to work with an entire 100,000 employee workforce. User on-boarding, user-and-messaging tagging, and data visualization must be usable and valuable at any point on this scale.


Task Flows

Before creating the initial concept wireframes, I created user task flows. Task flows were flow chart diagrams that contain screens, each with a descriptive title and a list of actions that could be undertaken on that screen. These actions either take the user to another screen, or take the user to a process. An example of a process would be 'Generate PDF Report' which would download a PDF report to the user's computer.

Task flows were important because they let me see the whole flow of the application, and were useful for discovering the alternative entrance and exit ways of the interface. They were also very cheap, and not time-intensive to make vast structural changes to the functionality and layout of the application. I used this time to experiment with alternative navigation ideas, and I iterated on layouts that created a simple mental model.

Task Flow. The first version of the Brand Amper task flow, including the notes in red after the first user test (done after the Initial Concept was made) where we decided to make the 'Tag' section a full navigational section with tagging of participants and messaging being under it as well.

Initial Concept Design

Once I had a clear and thought-out task flow, I started to design the initial concept wireframes. These initial wireframes were rough and did not contain much, if any, detail. An initial concept includes the minimum amount of detail to test the assumptions and navigational layout created in the task flow. They were only in black, white, and grey, and did not include any example content other than where it was required.

Once the initial concept was completed, it was important to test it quickly and throughly. As I progressed through the design process, the cost of making large changes increased exponentially, so if there were any sweeping changes, one would want to discover them at this stage. To test the initial concepts, I created a test script that had a number of tasks for the user to complete using a printed paper prototype. For this Brand Amper interface, I wanted the user to do the following:

  • Send an email to every participant who has a tag signifying they are in the Marketing department.
  • Alter the messaging that gets shown to the Sales and Marketing teams (tagged: 'Sales' and 'Marketing' respectively)
  • Import a list of participants from a valid CSV file.
  • Remove the 'Pilot' tag.
  • Discover what messaging is most used by the Sales Team (tagged: 'Sales').

The diverse range of tasks meant I was able to test my assumptions about how users would built their mental model. One issue that arose during this test was that users didn't have a clear understanding of the relationship between a tag and the messaging that goes with it. To fix this I altered the navigation to give tags a more prominent role, and redesigned the messaging screen to allow for searching by tags, and showing the tags as an atomic 'token' design. In later user tests, users were able to find tagging-related messaging features faster and more consistently, and when questioned about it, were able to give a clearer and better explanation of how tags worked with users and messaging.

Iterative Detailed Design

Once the initial concept was created, tested, and iterated upon to the point where I was comfortable with the flow and feel of the application, it was time to develop the detailed wireframes.

Detailed wireframes are detailed visions of what the actual application would look like. While my initial concepts took liberties with what a block of information would look like, the detailed wireframes were fully fleshed out, so that a visual designer could take them and design, pixel-for-pixel, what a finished product would look like.

Information Design

One of the most interesting parts of the detailed design of the application interface was the report. The report required a lot of data about the current state of the client's efforts to be shown in a clear, and easy to understand, visual way.

The key question when designing the report was: "How can we highlight and expose the most valuable bits of data?"

This seems like a fairly simple question to answer, but this data was meant for a number of different people in different roles:

  • The Community Manager who is running the scheme within the company. She checks on how the scheme is going, and how to improve it. She wants an overview of how the program is progressing.
  • The Chief Human Resources Officer. She wants clear and visual ways to demonstrate to other departments how valuable her team is to the whole company.
  • The Marketing Department. They want information so that they can align the company branding toward how the best employees view the company.

Working with the team at Brand Amper, we agreed that the information that should go first is the overall summary of the current participants. We wanted to show how many people had completed the process as a proportion of all involved. To research how best to visualize this data, I studied Edward Tufte's books on information design. We mocked up a number of options including pie charts and accumulative line graphs, but ended up settling on a more simple color-coded dot representation of the participants with a key, highlighting the numeric data in a simple table (see Figure 1).

The key to showing value beyond the Human Resources department was to give useful data to other departments. The second piece of data in the report was a keyword analysis of the stories of the participants who had completed the program. This was then be separated down by tag, so one could compare the brand value propositions of the Marketing team compared to the Sales team, for instance.

Figure 1. The report's summary and keyword analysis; two of the most important and valuable pieces of information are at the top of the report, the most important data to be acquainted with if you read nothing else.

Designing for Accessibility

As with all applications, it was important to design for accessibility, so when designing complex screens it was important to consider the implications of using the site with poor vision, or even a screen reader. When using a screen reader, buttons that are ambiguously titled (e.g. 'Click Here') have no context and are unusable. It was important that throughout the design every action was well described in the button that triggers it, and navigation had a clear hierarchy that wasn't dependent on visual styling.

User Testing & Design Iteration

During the detailed design, it was important to continuously test our assumptions we made in my designs. While it was unlikely I was going to make sweeping changes, this was where I could remove the micro-issues that prevent a good product from being great. The refinement that was provided by testing and iterating allow is to purify the product to its best form.

Throughout the design process I was keep to do a quality check to see how new users (who hadn't seen the application) felt. As a result, at every user test, I always asked myself the question: "Can people use this product as I intended?" I continued to run the tests mentioned earlier, which were slightly modified to hone in on the feature or screen that I was validating.

An example of feature iteration was that, in an earlier design of the Brand Messaging screen, the user would drag messaging from a pool of all messaging into a pool of specific tag (for instance, the 'Marketing' tag) messaging (see Figure 2). It became clear in user tests that users were hesitant to do this, because they were worried that by dragging the messaging out of the general pool and dropping it into the tagged pool, they were going to remove it from the general pool. I mocked up an alternative (see Figure 3), which ended up being the design we went with, which had the user add tags directly to the messaging itself. This cleared up confusion about a piece of messaging being prescribed to only one tag, as there is always a bright call-to-action to add a new tag to a piece of messaging

Figure 2. Brand Messaging before the change. Dragging a piece of messaging out of the 'Default Company Messaging' into a tagged pool was confusing to some users we tested with.

Figure 3. Brand Messaging after the changes that resulted from user testing. Messaging pieces were altered to have large calls to action on them to add more tags, and filtering could be done with the search box. It also now allows for bulk actions to be done to large amounts of messaging at once.

When I was designing the keyword categories on the report, the initial design had the category, the percentage of participants who used keywords from that category, and a small word cloud of the keywords used by those participants (see Figure 4).

In user testing, it became clear that marketers wanted more detailed information to analyze how employees saw the company, and what employee branding efforts were most successful. To improve the experience for marketers I created a pie chart which showed the various categories based on the number of participants who identified with those categories (see Figure 5). Selecting a segment of the pie chart altered the card underneath the chart and filled it with information about the category.

Figure 4. The initial design for the Keyword Categories in the report. The marketing users we tested with wanted more information in the report, thinking this wasn't enough.

Figure 5. I completely retooled the Keyword Categories to have a pie chart based segment selection paradigm. Selecting a segment of the pie chart alters the information shown in the card below it.

After the iteration the card contained a keyword analysis of the top five tags in that category, and allowed the user to compare categories within tags, and even provided a little statistical analysis to show how tags related to one another, and a tidbit about how the data was analyzed.

When I tested this new keyword categories screen with users they were able to understand and analyze a lot more information than with the previous design, providing more accessible value.


The Brand Amper project was a great opportunity for me to work through the entire User-Centered Design process, starting with a brief, working to understand the users and developing personas, taking their needs and existing pain points and developing task flows and initial concepts, and then testing those and designing the detailed wireframes. All the while, testing my assumptions and ideas against real people who are seeing the product for the first time.

The project was a success for Brand Amper, and the detailed wireframes were used by the development team to build the software product at DeveloperTown. The detailed wireframes were also used to sell to their clients; I received the following email from the product owner at Brand Amper after finishing the report screens:


I don’t know how to thank you enough. You manage to come through again and again for us, and we are deeply appreciative.

I know you probably had packing to do last night and it means the world to us that you took the time to get this done. Jason has a meeting with the CEO of a big company which could be a potential investor or client. We’re going to use this mockup and it is going to make all the difference.

Have a safe flight and enjoy your time off. I hope you keep it a vacation and don’t work too much!

Thanks again, Ben


This was a project I worked on whilst working as a User Experience Designer at DeveloperTown. All of the screenshots are from the final deliverable I created. I was not the only person working with Brand Amper at DeveloperTown, but I was the one entirely responsible for the design of the administration interface.

All of the digital design work for the Brand Amper project was made in Sketch, the great interface design software from Bohemian Coding.