The client came to Method for a multi-phased redesign project of a social network concept with gaming dynamics in mind. I was involved in the latter phases of the project for more than 4 months. The major task during my involvement was designing a few new web applications, as well as redesigning a large number of applications with a systemic consideration that not only tied all the apps together, but also fit them within the UI conventions Method had established during previous phases.
I was in charge of refining the project concept and producing detailed wireframes and specifications for many apps, but the one I found most interesting and challenging was an app that visualizes users’ daily data in different types of charts. The biggest challenge when designing it was figuring out the logic of how different types of input data affects the output charts. Specifically, there were two problems: 1. What kinds of charts are available to visualize a certain type of data and how do we present them. 2. How to design a simple and clear form for users to choose what type of data they want to input and how it will be charted.
My approach involved coming out with many use cases and documenting all input variables applicable. Based on the variables, I sketched out different types of charts to visualize them, and analyzed how they can or cannot be applied to other types of data. The outcome was a documentation listing what type of charts can be applied to a certain type of data, and what kind of data can be visualized in a certain type of chart for cross reference.
Choosing between consistency of UI conventions and creating new, unique components for a more interesting experience was also a challenge because there were so many apps and existing conventions to consider. Most of the decisions I made were based on examinations of how much value a new component can bring to users. If the same value can be achieved by an existing component, I will keep it consistent with the conventions and vice versa.
Some of the apps also required systematic thinking to define how the same app behaves on a global level as well as on lower levels, and the relationship between those different levels. For apps like that, I made charts mapping out all the possibilities of where the app will exist across the whole site, analyzed how each one of them will behave, then thought about their relationship to each other and how this will affect the UI on different levels.
Detail matters. A designer cannot only design for the obvious: neglecting a certain use case or detail may break the whole system. It is our job to think thoroughly how a design will work at both the back end and front end, and consider all the possibilities.
Considering all the possibilities does not mean including everything in the design. It is also important for a designer to make decisions about what’s not needed to keep a design simple and elegant.
Think about users when designing. In this project specifically it meant how to hide all the technical details from the users and design an interface that they will understand and enjoy using.
It is the designer’s job to critique and even say no to clients’ ideas, but at the same time, we need to give clear rational about why it’s not the best solution, and provide a better one.
Consistency is important for both efficient design and implementation, and it’s helpful to reduce users’ confusion. However, it is not an absolute rule; when necessary, modification or introduction of new things can bring a better experience to users.
Design within a system requires thinking on both micro and macro levels: not only how a specific UI works in a specific screen, but also how different UIs relate and affect each other.
[next: Method NCAA March Madness]