* Joined project at 6th of 9 months of development.
• All-encompassing cancer patient support experience promoting personalized medicine
• Hard ship date - 71 days from start.
• Requirements locked down to MVP.
• Soft launch to a small audience.
• QA 3 weeks before ship date
• Moderated Testing post soft launch.
The intention of this app was to help cancer-diagnosed patients and their immediate supportive social circle by providing a swiss-army knife experience encompassing a dedicated social network, messaging system, knowledge base and introspective articles, clinical trial search, the ability to take notes, bookmark articles and record doctor visits (and attach images/audio/bookmarks/notes) as well as promoting company's own personalized medicine.
The company had one designer who had designed about half of the app. Informational architecture was not yet done and the app already had an advanced dev build, which though still fairly bare-bones was far along enough to make a hollistic reproach a post-launch deal if the deadline were to be met; A homescreen with main article content selection and an interim arrangement of 'shortcuts' on the navbar pointing to features hidden in the 'center menu'.
Apart from the dealing with users’ sensitive health information, the unique challenge in this development was to be vigilantly sensitive to patients and their friends and family members who may find themselves at any point on the emotional rollercoaster that comes with dealing with such hardship.
In terms of development, about half of the experience was wireframed. Skinning had to be re-done because the current visual style didn't mesh with the app's intent, and the app was already partially built. Informational architecture map was done at the start of the development, but requirements have changed dramatically; support for half the target audience was dropped for MVP and some of the non-linear user data input features were combined and needed urgent detailed wireframing.
Apart from visual cleanup for legibility and ease of navigation, it was imperative to solve for every major feature screen visually and work those details out while building out assets to hook up a robust interactive prototype.
Tech savvy people business types, grandchildren, children and friend supporters in the 15-45 category, guardians and medical professionals.
Explorers and Medical Team were not selected for the f part MVP.
Every company has a unique workflow, but roughing out the experience on the whiteboard with the team (not just product, developers as well if possible) is a quick way of pooling the opinions, building concensus, informs the wireframing and begins to set realistic expectations for what can and cannot be built in the time limit.
Through the use of Smart Layers and Layer Comps in Photoshop, I was able to keep a versioned master file containing everything encompassing a section of the experience organized into individual screens in a user-flow story that I could drag&drop into inVision to connect into convincing interactive prototypes. Because of the way I build the files, I can quickly amend existing screens and create new screens on the fly.
If and when desired, the overall design elements can also be updated on-the-fly. It also allows easy exporting to both assets and a comprehensive iconography source for any designer in need of assets to build new screens. Smart layers allow instancing which helps keep the file size down. Because the files are hierarchically organized and made to-scale, speccing is easy and becomes even easier to set up with tools such as Specctr.
Mocks from Live
The interface colorscheme was reminiscent of nurse’s scrubs, which wasn’t necessarily the association you'd like the users to have as they will no doubt have already spent a lot of time in medical environments.
Since this could be easily globally changed later, much of the wireframing was done in high fidelity (to nail down some of the interface) but in monochrome.
inVision supports importing directly from PSD files, utilizing Layer Comps and Layer import with specific markup. However, even if the comps are numbered, inVision doesn’t necessarily sort the files sequentially, so interfacing with inVision becomes about leveraging the difference between keeping the files small and organized. The smaller the size, the more moving parts there are, which isn't something you want especially if you may be sharing the file with other designers who want to user the assets to build their screens. Keeping the file size down can make the files faster to deal with because of the way Photoshop handles PSDs in the memory, but it comes at the price of keeping the files effortlessly organized and the ability to use instances. Fortunately storage is cheap and plentiful and online file transfers faster almost as fast as usb 1.0, so the 10-20% filesize boost is a worthy trade-off.
Implementation doesn’t always match the design. In fact, I'm yet to see it match 100%. While sometimes this is the case due to technical limitations (like leveraged cocoa control libraries) or time constraints, in this case the previously delivered specs didn’t provide enough detail for dev. To save time on speccing out each screen separately, and because many screens had recurring elements, a general ui style guide was distributed to the team and updated regularly. This is especially useful because the whole dev team uses the same page to build different parts of the app that apply. Speccing per-screen just opens up room for errors.
With a bounty of features that went into the MVP requirements, question answering system inside of the doctor visit recording feature had to be separated out. Some visual bells and jingles (blured transparency) were omitted out of memory concerns.
The app was built with enough time for proper QA.
My only wish is we didn't have to make the more menu a destination.