Design Process
‍

Research

I asked myself a few basic questions to kickstart the project:

1. What are the typical user objectives for Digital Asset Management websites?
2. What systems are already out there and how do they structure the data that they have to work with?
3. How do other systems sort their assets, and are there similarities I can use to sort through the client’s library?
4. What features are most common in these systems and do they make sense to include them for our purposes?

The answers to these questions shaped how the team and I viewed the objectives and developed a structure for sorting out the categories. I kept referring back to the objectives and what the client wanted out of the product while I did my competitor research. Looking at what products were already out there I listed features that I could use for the client's DAM (Digital Asset Management) system. I then got started on sorting and prioritizing the features and sections that were requested as well as new features that could be implemented.

Sorting

Using the research I gathered and the client’s requirements we started sorting which categories/pages made sense to prioritize.

I knew that seasonal campaigns were very important to the dealers, so I made sure to make that page the most important and first to be seen. We grouped the rest of the sections into two other categories: Products and Resources, followed by the Shop. Products housed all the product imagery, brochures, flyers, and manuals for each specific products, while Resources became the hub for documents, brand guidelines, publications and logos. Shop would be a separate section that involved an e-commerce aspect to the website.

Information Architecture

Keeping the client informed, we worked together to structure the site’s information architecture.

We iterated, and talked about changes such as removing the “Shop” in the over all system, or the ability to download Vehicle Waivers and Manuals. I was concerned whether the Shop would be used enough to warrant the build, and I felt we were packing too many features for the first build of the product. Through these discussions we developed a system map we were all happy with.

Laying down the groundwork or the skeleton is one of the most important parts of the design process. If there are changes to the architecture during the design process, more time would be invested in changing the affected user flows. We wanted to be time efficient and nail down a system map we were all happy with so we spent a good amount of time rendering different user flows such as downloading marketing campaign assets, viewing specific products and downloading imagery. We wanted to make sure that the path to achieve these tasks were straightforward and made sense for the demographic’s needs.

Design Iterations

We made sure to always design for mobile first throughout the design process. This ensures that we focused on the most important functions without making the flow too complicated. Considering the audience, we wanted to keep things simple and to the point. As with any project, there were a ton of iterations from initial wireframes all the way up to the final prototype.

As the project progressed, our team designed the Marketing Campaigns page and followed the web principle of progressive advancement to keep the flow from being overly complicated. Progressive Advancement is designing for a smaller screen size first so the most basic functions are accessible, before adding more complicated interactions for larger screen sizes. We took pieces from the Campaigns page such as button, text, and image styles that were similar in the majority of the categories and pegged them as symbols. These symbols became the first few components to the design guidelines we later compiled for Hand-Off.

Once we were happy with the Campaigns page and approved by the client, we created the rest of the product page by page. There were a few revisions from the client that affected some user flows, but we worked with them to explain our perspective and compromise for solutions that satisfies both client and user needs.

Handoff

Once we started to create approved interface patterns and symbols, I started thinking about what the developers would need in order to build the site.

So while we were designing we started building a document that housed the design guidelines, and specs for the site. This was given as part of the hand-off package along with assets they’ll need. The design guidelines could be used for consistency if there were new components the client wanted to add to the system. Not only are the design guidelines a way to help the developer build the product, but it’s also a way to ensure consistency if a new section or component were to be added to the system in the future.

Overall, I think we created a product that satisfies the needs of the client as well as creating an intuitive experience for the target audience. Though there are some user flows I’d like to modify such as the purchase process, and downloading content, given the budgeted time I’m fairly happy with the end result of the design.

Unfortunately we weren’t involved during the development stages however we checked in with the client periodically on whether there were necessary changes and assistance the developers needed.

One of the best things I’ve learned from this project was to be diligent in communicating the reasons behind my design decisions, but also respecting the client’s perspective. The lesson boils down to differing perspectives - we as designers try to see the product from a user’s point of view, while the client sees the product from several others such as a business, administrative, and management perspectives. The only way for a designer to consider these viewpoints is to include the client as much as possible in the process.

Prototype