Next Case Study:

Angie's List

 This project was conducted under an NDA so the specifics of this project cannot be shared publicly

Understanding an entirely different type of user
  • User Research
  • Object Models
  • Workflows
  • Wireframes
  • Visual Design

Project Summary

Docker came to us looking to start a new project. Docker is an open platform for building, shipping and running distributed applications using what they call standardized "containers." DockerHub was meant to be a centralized resource for container image discovery, distribution and change management, user and team collaboration, and workflow automation throughout the development pipeline. Now when they told us this, I had absolutely no idea what they were talking about. I had never worked on such levels of engineering or DevOps. But by diving in with research of the space and interviews with users we were able to get up to speed in a very short period of time and build a solid experience for Docker users. Docker already had some pieces built out.

Screenshot of original Docker page

Ramp Up

Like many larger projects we started with a Ramp up phase to get on the same page as our client. Before we can start to design for these users we need to fully understand them, their needs, and their problems. So for a couple of days we dove into the world of our Docker. We spent a few days in the Docker offices meeting with the team, speaking with users, and examining the current products. We also spent some time researching other related products like Github, Bitbucket, etc.

Model of current Docker system, made after ramping up

Scenarios

We worked with the team at DOcker to come up with several sceanrios to design for. We wanted enough scenarios to get good coverage across the product. We did not use high fidelity personas but we knew that were different types of users who would be coming to DockerHub. We constructed the scenarios around these different types of users. For example a new new user who has just signed up vs. an experienced user coming back to his dashboard.

Workflows

After getting the senarios finalized, we started constructing some workflows. We started by sketching and working through them on a whiteboard. Because the scenrios were so flushed out, and because the product management team at Docker had done such great work, we were able to dive right into the detail of the workflows.

Whiteboarding out possible workflow iterations

Once they initial flows were flushed out enough we moved onto more detailed versions. Some of these workflows even had to included a user jumping back and forth between the terminal for different information, or to complete steps in the process that couldn't be done from the web.

Example workflow

We were building out an entire site and application, so to make sure we had everything documented we mapped the entire site. This was necessary because there were several pages that the scenarios and workflows did not cover not included in the workflows.

Example sitemap

Annotated Wireframes

After getting the workflows and architecture down we got started creating wireframes for the "Key Screens." of the product. We started with conceptual wireframes and worked with the team at docker for about a week or so to iterate and build them up into very high fidelity annotated wireframes. Annotated wireframes are one level above regular wireframes, and one step below visual design and interactive prototypes. They map out state changes, animations, interactions etc.

Example Annotated Wireframe

Testing

There were several ways we were getting feedback and input from Docker users, but one important way was to test some of the flows we built. We used usertesting.com to get the right type of user (we needed a very specific type of developer) and have them run through certain flows on the site. We were looking for certain areas that got them tripped up or confused, or even stuck. With Usertesting.com we were not able to talk to or help the user (the tests are done remotely and recorded), but it ended up giving us some very honest and helpful feedback.

Visual Design

We also had a visual designer working with us on the project and I helped polish out the mockups, the style guide, as well as spec out the mockups for the key pages. These were some of the many things we handed off to the developers on the Docker team.

Example mockup spec

Conclusion

I learned so much from working with Docker, they were a very passionate and effective team. The most exciting part of this project was diving head first into a world I knew nothing about and then only after a few short weeks feeling like an expert. Docker was pleased with our work and we ended up working with them on several other parts of their product.