Kellie Verne

The way this comes together varies, but ideally, there is a constant:

Deeply collaborative ideation

This is one of my favorite parts of any project. I love to see what insights develop from cross-functional/multi-disciplinary sources. Key outcomes may be different for different people. Collaboration provides the space to get different points of view on the table (or wall), and uncover potentially unexpected solutions.

Most importantly, collaboration develops a shared understanding, a shared mission or goal, and promotes trust, accountability, and pride of ownership for each team member.

Early-stage sketching/whiteboarding helps to begin envisioning an idea, or talk thru a specific (or subtle) detail with a developer.

Personas / User Types

Loosely defining a user's context, pain points, and needs helps better determine usage and behavior patterns of a target audience.

When developing personas (or user types), I coach stakeholders into performing an exercise: Look at the [system/product] from the user's point of view.

Wear their shoes long enough to understand—and better articulate—what they think their users needs are. We can then validate those assumption later.

Shifting the mindset away from a typical "business model" into user-centered thinking helps stakeholders to  empathize with these various personas to address the overall usability, intuitiveness, and experience of the product:

• How is this useful to me?
• What benefits/values does it provide?
• Do I like using it?

After personas are developed, they become easy-to-remember reference points used during planning and decision-making processes. It also gets the stakeholders aligned around a target audience for more meaningful discussions around value propositions, ultimately serving the needs of their users.

Sketches, mockups, wireframes, and prototyping

Fidelity has its place, and depending on the interaction required at a particular point, these can be anything from sketches on a napkin to coded, functional prototypes.

I facilitate brainstorming sessions to determine functionality (and possible solutions).

Invariably some level of sketches, mockups, wireframes and coded protoyping occur as a result.

IA, UI and IxD

Questions to Ask

1. How easy is it for the user to know what to do right out of the gate (affordances)?
2. What is the appropriate design based on the user's device (TV, large monitor, laptop, tablet, phone, or a watch)?
3. Is it consistent? Is it natural?
4. Will it work no matter what pathway they choose?
5. What if they get stuck?

I also do Information Architecture (IA), creating the best way to organize information and content. This can include taxonomy, content categorization, site maps, process flows, and options available depending on the user journey. Not only is it an integral component for the building process, but IA helps team members attain a bird's-eye-view of the project. This is also a great checkpoint for demonstrating usability.

Before beginning User Interface (UI) design, a very strong understanding of a workflow and how the user interacts with the system (Interaction design or IxD) must be established, at least as much as it can be at the time. Since this is what the user sees, uses and interacts with, I define:

1. What the best elements are for a given task(s)
2. What needs to be visible and when
3. What happens when a user clicks, taps, swipes, "interacts" (how it works)

Visual Design, aka The Icing on the Cake

Perception, a vital component of a user's experience, evokes emotion.

As a visual designer for over 25 years, I've always advocated for the end user. And since half of the human brain is dedicated to visual processing¹ , typography, color, spatial arrangement, and imagery (overall look and feel) will always remain as a high ranking officer for any product.

In Summary

Successful design is not an exact science (nor is it really science at all). But by applying the right amount of combined methods, strategies and processes when and where appropriate, we can not only help people do what they need to do, but make it enjoyable. Or even fun.

Get the Recipe!

Discover: interview, listen, interpret, identify.

Organize and Measure the ingredients:

User profiles and needs, brand guidelines, technology, business goals, other components and variables as the recipe dictates. Validate assumptions.

Cook:

Develop information architecture, functional requirements, interaction, visual design, validate, test, and build.

Taste!

Prototype, test some more, monitor, and if the recipe needs tweaking for an even tastier cake, iterate.

Note: Never consider your recipe perfected, either. Tastes change, cooking methodologies evolve, ideas are shared, discoveries occur.