DATA PORTAL
This was a product that had been neglected for quite some time, and suddenly became a priority for a company I was working for. It was an existing product, which I was assigned to as the only designer, to work with one PM and one engineer. Together we created a schedule for a stepped process to completion. There were three stages, of which I will only be showing you the steps involved to the final stage – The Overhaul.
Proto-personas
As a precursor to establishing the audience, porto-personas were established as a spring board for all efforts moving forward. Three user groups were established; Publisher, Developer, and Citizen (later became Data Journalist). A Publisher was our primary user which was more of an admin role than a consumer, however, they still interacted with the product and had distinct needs of their own, publishing the data to be consumed. The developer is the super user which is more privy to the functionality and primary objective of consuming data via the provided API's. The Citizen has more basic needs but needed more of a hand-holding experience since they were the least tech savvy of the three. The Citizen's primary objective is to filter numerous datasets for various discoveries pertaining to their needs.
Establish Feature Sets
A step I am not showing that took place between the Proto-persona stage and what you see below. This is a large document that I use to extract, and record the existing products features, navigation, etc. I use it to identify the IA, existing features, and content. Based on the redundancies, and content, I can identify the some high level groupings and begin to identify how they relate to each user group, or persona. The redundancies are what identify opportunities for simplifying the IA and content. I also use the document, in tandem with flows and site diagrams, to demonstrate how the product is being simplified, without losing any functionality. I'll show you that in a second.
Features Per User
Once the groupings have been established, I list them and rate them based on perception of what features are most important to each user group. Recording my perception of user needs is a point of reference for questions asked during user interviews and improve on my understanding of the level of importance established after the interviews. You will see that I have recorded some ideas that I noted as I was going though the existing product and revamping the IA. These are based on my perception of what the users goals are, and what can either enhance the experience, or fill in a potential gap.
User Interviews
After I had captured the structure of the existing product, its capabilities, and perceived level of importance per feature, I conducted user interviews. I worked with engineering to extract a list of current users, then reached out to colleges and various other online resources to establish a mailing list. Once the the list was created, I set up a Google Survey that filtered the participants to identify the group they fell into, and the level of relevance to the product. The survey had dependencies built in to make the distinction between a Publisher, a Developer and a Data Journalist (formerly Citizen) so I knew what questions were relevant to interviewee. I chose 8 from each user group, conducted survey's, recorded the sessions, distilled the feedback and moved forward accordingly. Below is the strategy I proposed to my colleagues prior to moving forward.
Flow Diagrams
Another portion of my documentation are flows. As I record the content and features within the existing document, I also record the various flows. This is by far the best way to document flows, but serves more as a site map, going a level deeper in recording how the user navigates around the product to achieve a variety of tasks. In an ideal world, this would then get picked apart and referenced when establishing flows for future design/development.
Portal Flows
There are two products I was faced with, but only one that I was tasked with redesigning. My assignment was to address the portal itself, not the administrative portal. I hope that males sense. Basically, there is a portal for the Developers and Citizens to utilize, and then there is a back-end, or admin portal, for the Publisher to manage datasets published to the portal. Below is a diagram I used to demonstrate 1) what the existing structure is, and 2) how I propose we restructure without losing existing content or features.
Admin Flows
Below is one of many diagrams used to record existing flows for the admin portal. Even though I was only assigned revamping the portal for Citizens and Developers, I kept running into dependencies that existed between the admin portal and the front-end portal, so I scrubbed the admin portal in order understand those dependancies and move forward accordingly.
Wireframes
Regardless of responsive design not being a requirement, I feel as though it is important to establish some spring board for responsive-ness whenever designing for web. This also helps with structuring the IA. Plus, it only does;t take much time...until it becomes a project requirement. But if/when it does, I will be prepared.
Competitive Analysis
Prior to re-skining the wireframes, we established our primary competitors, and I went through a quick analysis. This was to have a high level overview of the landscape, in order to identify opportunities to make ourselves distinct...at the very least.
Brand Identity
I went through over one hundred sketches while conducting each phase of the project. Whenever a concept would come to mind, I would jot it down. Most of them were cliche, such as government buildings, brackets, etc. but some of them really began to take on a personality of their own. We had a diverse audience (government officials, developers and citizens) so we wanted to be approachable without jeopardizing a level of professionalism, and quality. The logo we chose was based on current trends. Sorta like the Linode penguin and Twitter bird. We wanted to be inviting and "hip" without being so overly creative that the point was missed. A friend of mine, whom is a developer in San Francisco, had fascination for squid. Although this is not a squid, its a jelly fish, it has a certain level of elegance and mystery associated. It was a descent start...I think.
UI Design – White Label
There are several moving parts, ever changing requirements, etc. which is common and the wonderful thing about what it is we do as designers. An added requirement was to create a white label page layout/template for agencies to own as a separate entity from the front-end portal. This was a way for the agencies to appear as though they are their own entity, separate from the massive collection of datasets, with their own distinct identity. Since I had everything documented up to this point, it was easy to understand what the agencies would potentially want on their page, what Citizens and Developers might find important, merge the two and design accordingly.
UI Design – Home Page
To give a little bit of a back story, what I found with the existing product is that not only was the navigation disjointed, leading the user from one section to another without notice, but the primary features were buried multiple levels deep. To give an example, there were breadcrumb navigation that might look like this:
Home > Organizations > Data Sets > Data Set One
If the user were to select "Organizations" they could be redirected to a dashboard they not visited, or another data set not related to the data set they were currently in. Also, all the tools for filtering the data sets and consuming the APS's were located on the page, "Data Set One". So what I did, based on the suer interviews, and everything leading up to this point, I identified the functionality of the page "Data Set One" as the primary functionality, and brought that page to the home page. The end idea was a dynamically loading home page based on the organizations, their data sets and whatever filters were applied.
Also, a clear call to action was established for user acquisition. The old product had a dashboard that provided tools for publishing,however, the admin portal was what all Publishers were using to publish data and was irrelevant to the other user groups needs. The new registration page established who the user was, which determined which dashboard they would see. So it was a more customized experience, over-all, for each user group.
UI Specifications & Style Guide
The UI was based on a Bootstrap framework, with D3.js for all the data visualizations. Once the wireframes were completed and signed off, I moved into fleshing out the UI. I took the Bootstrap grid, snapped every UI element to the grid lines, and adjusted until everything was aligned and in place. I moved from a black and white color scheme, into a color pallet that was established in the competitive analysis phase. Most of the Bootstrap elements were addressed to some level of detail and delivered for development.
Login Experience
Below is a custom login experience I was playing around with for this project. I felt that adding some personality to the brand would create a sense of delight to enhance brand awareness.
This product was/is built on CKAN which is an open source data portal software that was not being supported...at the time. the strategy was to move away from CKAN for the front-end and rebuild from scratch using Bootstrap, D3.js, and WordPress (for pages relative to marketing content). The over-all idea was to boost user acquisition. We addressed this issue by placing the primary features on the Home Page as a way to incentivize the product by delivering the value proposition prior to creating the account. The only way to do that was to know what the users were after, and deliver it in the most simple experience possible.
This was a real project, not a portfolio piece. It is one of my favorites because it allowed me ownership, to test my processes out, and collect real user feedback to base my design decisions on. It was incredibly rewarding to identify opportunities to simplify an incredibly complex product from a six layer deep experience, down to one.