Proposal Builder

A system to streamline the creation of funding proposals for job creation and a stronger California economy.

Proposal Builder

Overview

We worked with a program associated with the California Community Colleges to help streamline the process of creating, distributing, and tracking funding proposals for new grants and educational resources. Most of the proposal creation process was happening either offline or using free online tools, so keeping track of proposal data was nearly impossible. The state needed this data in order to monitor the success of academic programs to more appropriately allocate resources, and to hopefully prepare our future workforce for emerging job demands.

Role

Design strategy, UI design, prototyping, HTML/CSS.

Tools

Whiteboard, Sketch, PatternLab, Sass (BEM), Mustache, jQuery, Gulp.

Process

This was easily the most complex project I've ever worked on. Working with a small team, we had a short timeframe to release an MVP UI showcasing a functional proposal creation process. In the beginning, a lot of our time was spent simply trying to wrap our heads around the problem, and all the details and considerations involved. Working close to the state government level meant having to understand multiple hierarchies, nomenclature, different data sources, and competing policies and goals from each community college.

Trying to figure how to wade through the overwhelming complexity.

We centered early UI concepts around the idea of breaking down the UI into manageable chunks, and separating each step into its own breadcrumb. The UI walks you through each step, rather than hitting you in the face with a giant form. The breadcrumbs also provide context and situational awareness. Where am I? How much more is left? Did I do this part yet?

Early layout UI wireframe.

With a rough outline in place, and requirements changing left and right, I started focusing on the pieces I knew would remain constant and gathered a list of UI components we would likely need. One advantage of designing 'atomically' is that you can still make headway even as the product requirements are still coming into focus.

Early layout concepts and inventory of required UI components.

My next step was to begin building out the modular components in PatternLab so we could get something in front of the client as quickly as possible and gather feedback. Once I had my bucket of LEGOs so to speak, I could start plugging and playing. Each component was written as a template in Mustache, allowing me to pass dummy data via JSON into the UI to test how it would hold up.

Disparate components floating around in the PatternLab UI, before being assembled into patterns.

This pattern-based approach to design proved incredibly useful when it came to iterating and improving the prototype with the client. For demos, we ran it on a local server so the client could interact and click through the prototype. Because each pattern was templated and set up with the proper class names and structure, I could easily make content changes to JSON files during meetings, which would instantly update the underlying patterns. This proved to be invaluable, as labels, dropdowns and titles were constantly changing and adapting as we worked with users.

An unexpected side effect of protoyping in the browser was people we showed it to often thought the protoype was the final product. While we were able to get great feedback early, we also had to educate the client on the nuances of how software is built. Software doesn't follow the normal rules when it comes to visible progress -- there is much more involved that is invisible. A database schema, API design, AWS architecture all tend to go unnoticed in a demo where all eyes are trained on the UI. So from the surface, it sometimes appeared as if progress was slowing, even though it wasn't. This is a helpful lesson that reveals a lot about how human beings perceive software. The interface is the product, and the product is the brand. This is why consistency, predictability, and ease of use are so important in UI design.

Budget page.

Metrics page.

Ultimately, we shipped on time, began beta testing, and spent a few months squashing bugs and iterating on user feedback. The main launch was so successful that the scope of work rapidly expanded beyond 'proposal creation' as stakeholders were looking to add more functionality and services. Moving forward, existing patterns will have to be evaluated to see how they hold up against a new wave of user goals and broader contexts.

Deployment Dashboard

A deployment tool for developers and project managers to create, configure, and monitor new services and applications.

Deployment Dashboard

Overview

Developers at a major academic journal company had no standardized or simple way to launch and configure services/applications for their company. Developers were spending lots of time setting up Github repos and managing configuration settings rather than focusing on development. Management needed a way to check the status of the product line. Our solution was to build a dashboard that aided in easy creation/configuration of new apps and services, and allow for a high-level view of the availability of all applications.

Role

Lead designer, sketching, user research, creating mockups, prototyping in the browser using PatternLab, and delivering production HTML and CSS to be converted into Angular application.

Tools

Whiteboard, Sketch, PatternLab, Sass, Mustache, jQuery, Gulp

Process

After speaking with several developers to understand the scope of the project, it became clear we had two main users that would be using the application: developers and managers. Developers needed a top down view, configuration options, settings, and power features. Managers would only usually need a top down view. It made sense to focus the app around the area where both user goals intersected, so I began thinking about the landing page.

The landing page needed to serve one goal: provide a high-level summary of the availability state (either available or unavailable) of a list of apps. A card based layout would provide room for a status component, title, meta data, and any action link we might need.

Stubbing out what a card based layout might look like.

Early explorations for the status card component.

Early iterations contained a “deploy” button on the card itself. But after some feedback, we decided this was a more deliberate action that should be contained inside the configuration page. Instead, it was replaced with a link that pointed to the URL of the app itself. I opted for a dark UI to blend in with the tools developers were already using, and hopefully increase adoption.

After building out the dashboard page I started thinking about the configuration options and the best way to display a growing list of controls. Part of the challenge was that the amount of options were in flux and I had very little requirements to latch onto, so the design needed to be dynamic and scalable. Tabbed navigation was the best way to do this because the tab list could easily grow as more settings were added.

What should the workflow look like? Does this UI support the goals of the user?

UI iterations for detail page.

Atomic design. Breaking each element down into modular components before coding it up in the browser.

The dashboard was designed to feel like a single page app with a flat information hierarchy. Both the creation form and the detail overlay controls slide over the dashboard page without completely obscuring it where clicking outside the panel dismisses it. I struggled with several ideas before landing on this. Should the app detail go to a new page? If it doesn't, how do I create a sense of layering without making it a modal? Does it work on a phone? Eventually, I landed on this drawer-style UI which eliminated the need for any signposting “you are here” UI, and back button, or page reloading by creating a strong sense of vertical layering. I also knew our Angular developers would be able to update any page component without fully refreshing the page.

At this point, I had a clear enough idea to start designing in the browser using PatternLab. Jumping into code early and not restricting myself to a set 'whiteboard -> mockup -> code' process allowed for the flowing of creative ideas and the ability to validate design decisions quickly. I could now test how the design held up on different browser widths and devices, and start introducing animation and state to the UI.

Getting into code earlier also meant our developers could start hooking up the UI to the API faster, even though it wasn't fully complete. As I built features and components, the team would update the production app, and we could see the final product take shape much faster than if we had taken a more waterfall-like approach.

Final implementation of homepage.

The slide over panel to create a new application.

The detail page with options to deploy, delete, and configure a number of options.

The major challenge I faced during this project was operating with very loose requirements. Many assumptions had to be made in the absence of strict user needs, and I often found myself designing with data that would be out of date in a few days. This forced me to iterate more frequently and not grow attached to specific UI solutions. Sometimes the only tangible data I would have to work with was a JSON object. However, designing and coding the UI layer in parallel with API development meant I was collaborating incredibly closely with the dev team and building a deeper understanding of the system, which ultimately led to a better product.

Restaurant Finder

A mobile app for finding restaurants on the go.

Restaurant Finder

Overview

The client had a rough concept for a mobile application to find nearby restaurants and bars by filtering by attributes. Are you looking for a drink or food? Want to eat light or are you starving? Expensive or affordable? The idea was to prototype an app around these quick binary decisions, and present an array of options to vote on, contact, view a menu, or share.

Role

UX, UI design, interactive prototyping.

Tools

Whiteboard, Sketch, Flinto.

Process

Early sketching and diagramming centered around workflow. What decisions am I making for search? What do I want to do once I see the restaurant results? Most people have a pretty clear idea what qualities they are looking for in a place to eat, but don't want to spend time fussing with filter controls or advanced search pages, especially on a phone or on the go.

Workflow diagram. Defining the best pathway through the experience before beginning to build UI.

Swiping has become a ubiquitous user interaction paradigm on mobile for a number of reasons. It's fast and intuitive if used appropriately, and generally requires less precision than a tap on a small target area. These usability differences are magnified on a smaller device; people using a phone are usually multitasking, walking around, talking to someone else, or outside in the sun where precise tapping interactions are much harder to use.

I spent time exploring what a swipe for a filter selection might look like. If I am simply making a choice between two items on screen, does it make sense to push something off the screen? Instead, I landed on a model for expanding half of the page as a way of selecting an item. Once filling the screen, it could automatically collapse upward, adding to a growing queue of selected filters. It was an interaction that was almost impossible to visualize without animation and gestures so I mocked it up in Sketch and brought it over to Flinto to prototype.

Interaction model for how panels should slide and collapse.

Mockup screens designed in Sketch.

Using Flinto allowed me to get a clearer sense for how panels should visually collapse and stack. It also helped spark a few ideas for transitioning between the filter view and the card view. This is another example of how working purely in static tools like Photoshop or Sketch can limit ideation, and restrict UI ideas to something more static, even though our interfaces are inherently dynamic.

Linking up screens in Flinto before animating transitions.

This project was scoped to a simple prototype and was delivered on time. Had we been responsible for implementation, I would be asking an entirely different set of questions beyond interface design and usability. Where does this restaurant data come from? Does Yelp have an API we can pull from? How do our filters (lively vs. intimate) map to their category tags? Why use this app over another food search application? What does this app/company sell and how does it make money? Business and engineering constraints are equally as important as design constraints and would need to be factored into the design to turn it into a feasible product.