I am a design apprentice here at fresh tilled soil and would like to share a recap of the first design challenge bestowed upon myself and the other apprentices. For the past few weeks, we have been discussing application design and the process one needs to take to conceptualize, prototype and build a successful tool. The challenge was to design an application for a given category (weather) that does only one thing.
I began my exploration by thinking generally about the weather. Why do people check the weather? Who is checking the weather? What are their incentives and what are they really trying to find out? Why?
There are a lot of different reasons why people check the weather and while some people really want to know the exact conditions, most people have ulterior motives. Many people just want to know what they should wear or bring (a raincoat? umbrella? etc). Others want to know if they can be outside with their baby or elderly parent. Some are farmers, dog walkers or people who work outside and the list goes on and on. This idea of people checking the weather to interpret it for an answer to their question resonated with me. What if we cut out the middle man and just told people what they want to know?
I began to sketch out several different ideas and consider pros and cons. An app for what shoes to wear? Too dependent on personality. Weather displayed with your phone alarm? People might dismiss the alarm too quickly. Will it rain? Too direct and not an interpretation. Should I ride my bike— hey, now there’s an idea!
The ‘Should I Ride’ concept seemed like a direction worth exploring further. I started simple. The application pulls in the weather and, based on a set of parameters, tells you either yes, you should ride your bike, or no, you should not. From there, I began to ask and find answers to questions that would determine how I might shape the rest of the application. Who would use this application? What would determine if a person should ride, and what factors play in to the answer?
The first addition to my prototype was allowing the user to select their bike riding skill level. I determined that an answer of whether you should ride or not should be based on how competent at riding a bike the user is. More advanced riders might be subject to slightly harsher conditions. I then determined there should be an account section, where people can specify and save their preferences. Some people might be ok with riding in the cold but not the heat, for example, while others prefer the opposite.
The next addition to the prototype was time parameters. With the city commuter in mind, an individual using this application may leave early in the morning but not return until late at night. The first prototype was built by just checking the current weather conditions but after checking it several times throughout the day, it became apparent that the application would give a positive answer in the morning and a negative in the afternoon. This would leave a commuter stuck in the rain!
The third parameter considered as a result from the prototype is distance. Originally the prototype was designed with the city commuter in mind with the intention of keeping a narrow focus on the user type and data range. But showing the prototype to other people revealed a desire for weather conditions on longer rides, both for more avid users who ride farther and to ensure a sense of trust that the application knows where the user is going and what they may encounter along the way.
The final consideration given to this application was how it would connect with the user. Given the simplicity, it seemed rather bland to just output a yes or no answer. What other ways are there that would engage the user? Is a yes/no response too cut and dry? The more exploration and thought given to the problem, the more apparent it became that often the result could be a ‘yes, but…’ or ‘no, unless…’. This opened up a whole new level of opportunity for engagement with the user. By creating interesting, fun tag lines, perhaps it would entice the user to check the application, even if they know the weather forecast, simply because they are curious what the response might be. Creativity with copywriting could add some interest to an otherwise straightforward application.
This exercise was an excellent exploration of the process of designing an application. Considering many different options and determining why one idea might be more successful than another, thinking about how the application could be applied in a variety of ways, pinpointing who it is for and what problem it solves are all crucial steps in the process. Creating a good prototype opens up questions that may not have otherwise been considered and ultimately leads to a better designed application.