I’m always surprised by what I learn when I listen to what people say about technology -- what frustrates, what delights. Spoiler alert: It’s never really about technology. It’s always about relationships, what’s important in their lives, and then later how technology might help.
Personas give faces to our primary users. They help us remember what’s important to the different people who will use our product. And, to leave off extraneous features. It allows us to carry around a concise summary of what we learned in the User Research.
Humans are hardwired to understand the world in stories so storyboards are a powerful but simple way to share ideas about a few possible solutions. It gives us something to show users and stakeholders to find out if we’re on the right track. If we’re not, it’s early enough to try again.
Everyone loves a flow chart…OK, nerds like me and anyone who is investing thousands of dollars in design and development loves flow charts. They capture what the system needs to do but also let the stakeholders know that we are all on the same page.
There’s never just one way to solve a problem. A great strategy uses a unique strength of the business to solve a substantial problem for its customers. A strong and concise strategy serves as a beacon, guiding design and implementation decisions.
The navigation, the headings, indicating the difference between eye candy or functional buttons — these are all decisions that are made in creating the Information Architecture. It’s not a time to be unique, trendsetting, or to buck conventions. Simplicity based on understanding the users’ expectations is critical.
Wireframes are when the design starts to come together in preliminary sketches to show layout and placement of content. Wireframes should be a stripped-down version of the full design because it doesn’t make sense to spend hours creating and aligning a set of icons that get thrown out when the product manager sees it for the first time.
Visual Design adds the color, typography, graphics and the all-important whitespace that signals the relationships between elements on the screen. Now the design is looking like it will look when it becomes real. But it’s still cost effective to hold off on “making it work” until the stakeholders and your users have reviewed it. Even though everyone might have agreed on the requirements, until it looks and feels real there’s a chance you’re not on the same page.
In this step, we make our visual design "clickable" so everyone can see roughly how it will work on a phone, tablet, or desktop. With prototype in hand, we can validate our design before going to the expense of having it coded. It’s hard to resist the urge to rush to market when the prototype looks so real. But the ROI from reduced development and support costs and increased sales will be worth it.
After the design has been implemented into a coded version, we take it to our users again and this time we sit back and watch them use it. At this point, we might learn that a feature sounded good but isn't really working the way users wanted it or that users miss something we thought was obvious. Again, we've saved ourselves from potentially costly mistakes by catching it before it is released.