Designing for User Goals

Last spring, we had a big problem on our website. One of our most-visited pages was a big ugly dinosaur falling to its knees, dragging everything else down with it.

As a remote user testing company, we have two distinct sets of users; our customers, with websites and apps they want to improve, and our test-takers, who sign up to make a little extra pocket money while providing feedback for the first group.

The “big problem” page was the dashboard for this second group. Upon signing in, a dashboard appeared showing the test-taker any available tests, their history of completed tests, and their qualification history.

The tester pool was growing quickly, and hits on our bloated old dashboard page were skyrocketing. With every hit, we were auto-checking for available tests, loading details of old tests and qualification attempts, and more. This was putting a huge load on our servers and slowing down the entire site.

In addition, much of the rest of the site had undergone a visual rework in the past half year, but the tester dashboard still retained the old UI fonts, colors, and formatting. Functionality-wise, it also hadn’t kept up with product changes and was no longer very usable. We needed a redesign.

Planning the re-design:

Describing our thought process

As we began thinking about the redesign, our process was framed by two considerations:

  1. User goals
    Thinking about users’ objectives on the page and how we could best provide for them, and
  2. Business needs
    Doing it in a way that met our needs, including minimizing server load and matching our new UI style.

First and foremost, the page exists to be used by testers, so meeting their needs was the highest priority for the new design. But it was also imperative to create a new dashboard that would satisfy the needs of our company. If we met both of these objectives, the redesign would be a success.

We started by making a list of what users needed from the page. We receive frequent feedback from our users and had a good idea of their priorities. We found that all testers fit into one of three broad categories reflecting different stages of the tester experience, each with their own unique goals:

  1. Unqualified testers
    Testers who have not yet passed their qualification test and are not eligible to perform website tests for customers.
    • ➢Their main goal? To become qualified.
  2. Qualified testers waiting for their first real test
    Testers who recently passed their qualification test and are waiting to take their first test for a customer.
    • ➢Their main goals? To get tests and be competitive as a new tester.
  3. Qualified, experienced testers
    Testers who have been testing with TryMyUI and have completed one or more customer tests.
    • ➢Their main goals? To take more tests and check the status of their performed tests.

After identifying these three groups, we compared their goals to the roster of elements on the current dashboard page (plus ideas for elements we could add). We then made a new list, itemizing each element that would help the different user groups meet their respective goals, and identifying each element that was not relevant to their needs.

We now had a solid foundation for the direction of the new design. We had precisely defined everything we would need to meet the goals of each of our three types of users and, just as importantly, everything we could eliminate.

Next, we defined our own priorities for the new design:

  • Minimize server load caused by visits to the page
  • Update the UI to match new visual standards
  • Improve tester performance quality
  • Reduce support emails


Creating a design to eliminate the problem

With these two lists as the basis, we formulated a solution for our redesign that would satisfy both.

Our idea was to treat the different chunks of information on the page as modules which would appear (or not appear) in different variations for testers in groups A, B, and C. We would use testers’ qualification status and number of tests performed to classify them and thus decide what to show.

This would be much more efficient than the old page design, which essentially was a laundry list of everything that could be shown.

An unqualified tester would now see only the “Qualification Tests” section, including

  • Link to take the qualification test
  • Rating and feedback on any previously taken qualification tests

and the links section

  • General guidelines for testing with TryMyUI
  • Example test video
  • Example written responses

Nothing else was needed. Every user goal was met by these elements, and everything else could be hidden.

On the other hand, a tester who is already qualified and has been taking tests for a while needs practically nothing from the “Qualification Tests” section. For these users, we would only show their approved qualification status and a link to expand the details of their old tests. But they would see “Available Tests” and “Performed Tests” sections in full, with links to take new tests and status updates on recently taken tests.

This paradigm would clarify the purpose of the page for users, emphasizing the handful of elements that would help them reach their stage-specific goals. Prominently showing unqualified testers their ratings and feedback would help them improve and prepare to pass. Condensing the “Completed Tests” section down to just recent status changes would help experienced testers see what had changed and where they stood.

The system would also minimize server load by hiding or collapsing all unnecessary elements. Anything that testers didn’t need right away could be put behind an “Expand” link, like performed test details for group C, or erased completely, like the “Available Tests” section for group A. Fewer items to load would mean less of a burden and improve site performance.

Critically, we also added a “Refresh” button on the “Available Tests” section. Many testers, keeping an eye out for new tests, had been regularly refreshing the whole page, meaning everything on it had to be loaded again and again. Providing a “Refresh” button was an obvious improvement that was easier for testers and much easier on our system.

Emphasizing ratings and feedback was another thing that helped. If the testers were encouraged to read the feedback they received, then the quality of the services they provide to our customers would improve.

We tested our designs with TryMyUI testers, made the necessary adjustments, and replaced the old dinosaur page.


After the new design went live, loading times across the website dropped by more than 70%. We were flooded with positive feedback (and a few criticisms and suggestions) from testers.

Not only did the page look nice and new, but it was much more intuitive and the general clutter of the old page was replaced by clarity. We even saw a marginal improvement in test turnaround time.

The new design, of course, was not perfect. We have continued to make changes and improvements as we talk to testers about what they need from the page while also thinking about our own ideas on how to improve the quality of our products.

This re-design exercise proved in practice something we already believed in: putting the needs of users first is not only compatible with business goals, but supports and advances them. Design for your users – it’s just good business! 

If you have any questions about user testing or site design and development, simply contact

About the Author:

Tim Rotolo is a UX Architect at TryMyUI, a remote usability testing tool that helps companies learn about the usability of their websites and apps. Tim is responsible for heading up UX research, design, and strategy at TryMyUI and has run many user tests on the TryMyUI website itself as well as a variety of popular sites around the web. Twitter: @TimoRoto


About Author

Partner Blog Author
We are pleased to have our official Partners submit informative, educational blog posts that we hope you find useful and beneficial to your organization!

Featured Posts