I’ve been designing and building web apps for years now, but I’ve never taken the time to document how I approach greenfield projects. To help me consider my own process and provide others with insight into how I work, I’m going to walk through the way I approach app design.
Many offices and public spaces are absurdly over air conditioned in the U.S.. This a huge pet peeve of mine! The amount of energy and money wasted to make a space miserable is beyond me. This is a problem (The NY Times agrees), and I wanted to take a stab at it.
A proposed solution
From working in various cold offices over the years, I’ve found that getting a few co-workers to back you up when complaining to the boss about “The AC” can go a long way. To that end, I came up with the idea of allowing people to flag any U.S. location as “Over air conditioned”. It’s a simple web app called Frrrozen (akin to Foursquare) with a succinct primary action. After you flag a place, you’re prompted to tell co-workers about your office’s Frrrozen Page so they can flag it as well. After that, just send the office manager a link to the page so they’re aware of the discomfort consensus amongst the ranks. For public locations, users are prompted to leave an “It’s too cold here” comment on Foursquare or Google Places pages after they flag it on Frrrozen.
I think this idea is pretty solid. That said, I do know from experience that building is often easier than getting traction or influencing usage patterns. Provided the product could get decent distribution, the main problem I foresee is intra-office adoption. Since I’m only taking this idea to the prototype/feedback stage (for now) I can focus solely on the joys of design.
When embarking on the design of a new product or significant feature, one should research the problem domain, market, existing solutions and also take steps to understand the product’s target users. In this case, let’s just say that’s already locked down.
Now that I know there’s less chance of wasting time and money… I can confidently move into the think-write-sketch phase. This is where I use pencil ‘n paper to visualize what the main workflows should look and sound like. I say sound, because copy is one of the most important parts of experience design. Apps are in conversation with their users — when used well, it aids in conversion and can remove the need for some screens entirely.
When sketching out workflows (onboarding, posting etc…), I draw out rectangles for the screens I think I’ll need, then I add candidate copy, controls and content blocks to each one until I feel I have something to refine. This is the “cheap” stage, so I try lot’s of approaches. All the while I’m considering potential service integration requirements (in this case Foursquare and Google Places APIs) and scenarios the app will be used in.
Once I feel good about the sketches, it’s time to put some wires together. But first, a “real world” note on wireframes. When I’ve worked on projects that already had a significant amount of hi-fi elements in Sketch or Pshop, I would use them instead of generic wireframe chrome. Making both lo-fi wires and hi-fi mocks in this case is usually redundant, exceptions being huge new features. But your mileage may vary.
Since the project is greenfield, I chose to build a lo-fi wire/prototype with Sketch and InVision. The sooner I can get a clickable experience in people’s hands the quicker I can uncover the big holes. Also, It’s not uncommon for the wires to come out a bit different than the sketches. That’s fine, it’s a normal part of the design process. Beyond general oversights, It often has to do with what I call the design-copy tug ‘o war. Often copy will seem fine in a pencil sketch but it won’t hold water when actually laid out.
After I feel like I’ve learned enough from the wires, I begin designing the hi-fi prototype and visual theme. Since the problem at hand is about being cold, I opted for a chilly palette and used an image that added some editorial pop to the landing page. I also ended up changing the app’s name.
You may have noticed that the app doesn’t require a logged in user… I went with this approach to lower the usage barrier (also why it’s a web app and non native). Pseudo user features like “how many flags have been dropped In a day” will be tracked via cookies. Sure, this limit can be “overcome” pretty easily, but the risk/reward still tipped the scales in the favor of usability. If the app took off I know of some future features that would require real accounts though. But hey, we’re doing the Lean thing right?