Notes on Design Project One

Wednesday, January 9th, 2019 | Module

Always work Topic > Project 

Research and engagement in the topic drives the project, not the other way around. Your job as a designer is find as much information as possible and use that information to create systems that work. Starting at the end and “reverse engineering” solutions to fit the topic is a major mistake, and sometimes major adjustments need to be made later. 

You might find yourself saying “It’s like ________ for __________”.

You know:

  • 2007: “it’s like YouTube, but for ______”
  • 2008: “it’s like the iPhone, but for ______”
  • 2009: “it’s like Twitter, but for ______”
  • 2012: “it’s like Facebook, but for _______”
  • 2014: “it’s like Airbnb, but for ______”
  • 2015: “it’s like Uber, but for _____ ”
  • 2016: “it’s like Pokemon, but for _____”
  • 2018: “It’s like Blockchain, but for ________”

This is the way a marketer or business opportunist might approach product design. It can be successful, or it can have disastrous results. It’s a “top‐down” approach, grafting a model onto a people. You should avoid it.

 


Stay in low‐fidelity as long as you can (until they drag you away)

Quick! Which of these two designers is getting work done?

Creating with paper can feel silly. It doesn’t really look like “complicated” work, or “real” work (One student in her journal referred to this work as “arts & crafts”). It’s difficult to test as well. It puts a lot of burden on the test subjects to abstract the experience based on the primitive symbols, signs, and interfaces in front of them. 

For this reason, an overwhelming urge exists to move forward into medium‐fidelity to high‐fidelity quickly, or at least “get it on the computer” so that the work feels real. Computers means that it’s real, right? We’re probably designing an interface for software at the end of the day. Also, the tools look much more sophisticated and complicated, so as a designer, we get to feel smarter and show off all of our key commands and font knowledge. 

This urge to rush to high‐fidelity actually costs you time. Why? Once problems are identified, it can be very time consuming and expensive to go back in the process if something needs to change. Implementing changes in a fully realized, released product can be disastrous. See the GoPro Karma.

“Unfortunately, the Karma, as a drone, proved to be too big and too heavy to compete with the svelte DJI Mavic. To make matters worse, just two weeks after it launched, the Karma suffered a full recall as several drones spontaneously fell out of the sky. The problem, it turned out, was a simple loose battery latch.”

-OutsideOnline​.com

GoPro no longer sells drones.

You should exhaust every possible iteration, ideation, and avenue available to you in low fidelity before moving forward. When there is nothing left to test or verify in the model, or the interactions, behaviors, or services, then begrudgingly move forward. When every drop of insight has been wrung from white boarding, focus grouping, sketching, modeling, diagramming, role‐playing, or simulation, tentatively move forward. Why? It’s just cheaper, easier, and more productive in earlier stages then later ones. If you are unable to answer questions unless there is some sort of form to interact with, you know it’s time to move to a higher fidelity.

 


“UX” is how it works end to end. It’s not just usability.

Usability testing should come after you’ve settled upon the interaction model. And UI is called “the interface” for a reason. Design isn’t just UX/UI — it’s the whole system! Try to keep yourself from dictating design from the interface. The needs of the interface are based on the learnings and observations of the interactions with the people through many of the methods we’ve covered. If you find yourself dictating interactions with expected downstream behavior from inside your software app, don’t do that.

  1. Write down the functionality you’re thinking might be beneficial.
  2. Next, find ways to verify that it’s actually useful for your target users.
  3. Talk to them, role play, act it out, prototype.
  4. Then fold it into the interface, and test it.

Observation of real people and role‐playing will lead you to where you need to go, from the needs of copy verbiage to error correction and more!

 

For example, what needs to be tested here? This design pairs up students who are walking home in the city with the goal of safety? If you said “the walking”, you’re right! These designers should set up walking tests and observe people as they walk home. Nothing is more real than real. The insights that they glean from observation will drive the form of the interface, bottom up.

So, get out of the lab…

Mid‐Century design genius S Neil Fujita says it better than me, we need only substitute “drawing pads” with “screens”

 

“Too many designers are still looking for answers and directions only on the clean, white, unobtrusive surface of their drawing pads. They do not bother to look beyond the edge of their paper. They have not learned to bridge the gap between their artistic purpose and their function in life.”

 


Ideate not just towards impact but also innovation

Always bias your ideation sessions not just toward impact but also towards originality and innovation in the space. You may get to a place of improved metrics but will not create substantial breakthroughs merely borrowing existing models. While incremental improvement is part of the design process, during ideation, don’t stop until you’ve exhausted the well. People will pay you for new ideas and fresh models. It’s essential. Synthesizing research into innovative solutions is very difficult to outsource or automate.

This doesn’t mean designers throw away what works, or put themselves in positions to re‐invent the wheel. If a design pattern is already proven, it should be leveraged (for example “chat” or “maps”). Don’t burn time building what already exists and has been tested. Instead, ask yourself:

“What’s different about my problem? What’s unique about this set of circumstances, interactions, and people?”

Don’t strive to make your solutions generic, strive to make them specific.

 

 

Even bolting a model on a problem doesn’t work for the behemoths. 

Uber for a recent redesign went with a new, driver‐centric emphasis for the redesign of their flagship driver app. It was so essential to change the thinking on this, the CEO got in the driver’s seat. If the CEO of Uber has time to do field testing, then you do too.

 


Design, as it turns out, is all around us.

So, there is lots of design out there in the world. And, actually, a lot of the time it was actually done by a non‐professional designer.

It doesn’t take much to find it. Here’s some examples along with some smart redesigns.

Don Norman Lights

Nikki Sylianteng


Breakdown the User Experience into small chunks to test it

As a goofy thought experiment, let’s propose a new product called Ubrr. This is a rideshare application and system designed to work in the Arctic Circle and northern areas of the world. It’s a system similar to Uber, but uses sled dogs as the method of transportation.

What do we need to simulate the experience of Ubrr? At first it seems impossible. But, we can break down the user experience into discernible interactions so that you can validate them one by one. Place each interaction on a post it, and then determine a test for each singular interaction. 

As an example, Ubrr needs to work in a polar environment. It’s very cold in the arctic, so designers will need to test if the mobile devices will work in the snow, cold conditions, and if the interface needs to be adjusted for someone wearing gloves. 

It would be impractical to fly to Alaska to test this small piece of UX! But, by breaking down the components of the interaction, each piece is testable individually. 

You could simulate the conditions of the environment with a freezer, and change the temperature of the freezer and measure the degrees until you log a failure. You could simulate the snow with water, and measure how wet the device could be before it’s untenable to use Ubrr. That just leaves gloves, which is easily replicable. You could measure density of gloves or thickness of the material. Analyzing and aggregating these results leaves a clearer picture for the designer. For example, the interface might need to account for drivers using gloves, with larger buttons or other types of affordances. While none of them are the same as an actual field test, they provide a lot more information and data for the designer.

Here are a few pieces of the hypothetical experience to consider:

  • Dogs
  • A Mobile App
  • A (musher) Driver App
  • System Control
  • Sparsely populated environments
  • Natural Environment 
  • Limited cell signal

 


Some words on objectivity

Being objective with other’s work is easy. Being objective with your own work is hard. Here’s some tips.

 


Your design question

What’s wrong here?

It’s impossible for the designer to have any solution for this question besides a parking app. (Oh… the parking app… ) There are lots of solutions to problems of parking spaces on 180 New Montgomery. One simple way to tackle the problem is fewer cars!

It can be tempting to craft your design question to support your solution, rather than the other way around. Remember when you were forced to ideate on another team’s question? Were you surprised by the variety of solutions both they and you presented? It’s your job to be as open with yourself during ideation when answering your own question. 

 


Testing and evaluation process

Think back to how objective you were when testing another designer’s Proof of Concept. Many testers were unconvinced and quite skeptical of the proposed interactions, and were unafraid to put the concept to the test, with dozens of results. 

However, there was a real reticence to put your own concepts on the line. Many students orchestrated tests to prove themselves right. Clearly, something has changed. 

It’s hard to kill our babies, particularly when we are asked to evaluate ideas that are still hunches or in nascent stages. But imagine the alternative: some feature could make it all the way to production because of personal preference or ego as opposed to need. This is anti‐design.

How to move beyond this? Well, testing a wide array of ideas keeps you from falling in love with one concept. Strive to find (and create) an environment in which the pressure is to get it right, rather than ship a product. Remember that the design you are creating is in the service of your users.

 


Scope

It sure is easy to recreate something that looks like Facebook! 

When you start talking with folks, they will start telling you their needs. And many of them might say they want something like a communications platform. The first problem, of course, is that this design already exists (We call it the internet). The second problem is that the project scope of a communications platform is way too huge. So, the trick is to try to not recreate things that are exist, or are already proven. You don’t have to redesign OS behaviors, since they have already been tested and are expected by your users. Many students included a chat function in their solutions. This is a major time burn if an already proven chat product is out there. Find the one thing that is unique in your specific problem scenario and focus in on it. Do just one thing, and prototype and test that one thing until it’s excellent.

 


Personas

You only need yourself to make all of this work. Believe it or not, you don’t need fancy worksheets, post‐it notes, or any UX jargon filled templates off the internet. You have all the tools you need at your disposal, which is a brain and a pencil. Don’t invent metrics for a persona unless it helps you further the design, and please don’t fill in generic persona charts you’ve downloaded or “found”. The properties of the persona should come from the groupings you’ve identified after analyzing your research. For example: listing the age, income, and vocation of personas based on students doesn’t make a lot of sense. These properties didn’t really change results of the interactions in any way. But, the program level (Grad/Undergrad) and progression status (Freshman/Sophomore/Junior/Senior) greatly biased results, and so were a much more useful grouping and property for a persona. 

How does 48% Conservative help this designer with this matching concept? How did the designer even come up with this number? What is useful here?