Profile: Who am I?

I want to change the world with you. Yes, really.

What's your next big thing? Are you trying to shake things up, and not just for the sake of "disruption". Do you have a great new way to unite people? Have you invented a way to get a traditionally tedious technology online and need to make it user-friendly? Maybe you're about to release the next major change technology and culture, enhancing education with technology and innovation, or simply improving the way people live, one internet-connected appliance at a time.

My name is Ezra Ekman. I have over 25 years of experience designing user experiences and building brands, and I can actually code the responsive sites and apps I design. And now, I want to design your next big thing. Let's get together and make it happen.

Or, If you're interested in more about my process and how I approach UX, read on:

User flow analysis Team Process

Where do I fit in your roadmap?

User experience design is important, but it's only one part of a much larger setting. It isn't just slapping some wireframes together and handing them off to developers. A UX designer must actively participate in the Agile process and Scrum sessions along with the rest of the team.

Team roles and responsibilities

Within these teams, each group has their own roles and responsibilities, though again this can vary in different organizations. The diagram to the rightabove demonstrates how UX can fit within the greater team, and where UX deliverables become useful to others.

What is my process?

1. The project kickoff

The first step in a major initiative is a kickoff meeting with everyone involved in the project. This is often split into multiple teams, which can include: creative and design teams, project management teams, and development teams, though this kind of segmentation does not always occur.

2. Gathering data: who to target & what to improve

Personas Personas

When designing to solve a problem or provide a solution, it's important to know who you're designing for. A user persona is a clearly-defined, fictitious example of a specific user archetype. It is usually created through from insights already known about users combined with data gleaned through user interviews. Full-blown personas aren't necessary (and are hotly-debated within UX circles), user-centered design principles (i.e. designing for specific user types) is an important part of UX design. Multiple personas are to used identify when you're solving a problem for one group of users, but also to be aware when solving one group's problem might also be creating problems for another.

Personas are then handed off to Project Managers and Product Owners so they can generate user stories based on product requirements. While this occurs, UX can interview individual users to determine what works about the current process, what doesn't, what's missing, and what pain points might exist that users don't even realize is affecting them. User stories and epics, combined with a detailed heuristic analysis of the current offering and acceptance criteria from stakeholders, allow the designer to get a clearer picture of exactly what tasks each user/persona needs to accomplish in the context of their greater goals. These stories can be as simple as a statement, such as "As a Learner, I want to find courses easily so I can register quickly," or as complex as a series of such statements embedded within a parent epic that uses multiple stories to describe a greater overall goal.

3. Flows & journeys: finding gaps in the current process

Task Flows Task Flows

Now the process of establishing task flows and user journeys begins. A task flow is an analysis of the steps a user takes to accomplish a task, whereas a user journey demonstrates the larger context of the user's exploration as they "journey" from awareness of a type of product or service to discovery of a specific one, comparison between similar offerings in the market, signing up, and using/purchasing something. A customer journey is similar, though may take a more marketing-specific approach rather than being focused on usability and accessibility, or may also include interactions between a customer and the organization outside of the usage of a web site or app.

These diagrams are useful in identifing potentially unnecessary steps in the process that can slow users down or create obstacles that impede progress. This is where user interviews become key factors in the UX process. It's important to ask questions, but it's just as important to watch as users try to accomplish tasks because they often don't even realize why a bad experience is bad; users often simply accept an experience as "the way it is", and can't always articulate why it's confusing or frustrating. But when you watch them try to do what's intuitive for them, negative patterns can become apparent.

4. Low-fidelity wireframes: a map, not a bucket of paint

Wireframes aren't design mockups; they're essentially blueprints for your web site or app. The benefit of wireframes is that they allow rapid iteration and prototyping without working about pixel-level design details. This vastly speeds up the design iteration process and allows quick changes and improvements in the user experience to be made. Wireframes are generated from the user stories if they are complete at this point, and review/feedback sessions can begin. Clickable prototypes can also be produced from the wireframes to gather early feedback from initial user testing.

The first round of wireframes are often intentionally low-fidelity. This means that most artwork is simple, if it is present at all. Images are often boxes and color is usually absent, and some content areas may simply be placeholders to be filled in later. Sometimes wireframes even take on a "sketchy" feel, to prevent stakeholders from accidentally reading too much into what they may see as the "design", since it is not yet present. This allows the focus to remain on usability without getting bogged down in the details. That said, not everyone follows this approach, and sometimes stakeholders have trouble visualing the final product when faced with low-fidelity wireframes - or they simply prefer to iterate on both usability and visual design at the same time.

5. High-fidelity wireframes, visual design & clickable prototypes

Once a wireframe is done, it's time to make it shiny. There is often some crossover between marketing and UX in this area, as visual designers can end up on either team. It's also not uncommon for a UX designer to have a background in visual design, which is true for me. Clickable prototypes can range from being based on low-fidelity wireframes to being pixel-perfect representations of a fully-implemented site - even to the point of utilizing live data sources. The purpose of prototypes is to gauge user acceptance and test the usability of a design before it goes live for a large group of users.

6. Content, UI assets, style guides & design pattern libraries

A complete style guide includes definitions for visual design and behavioral specifications. However, it doesn't take much to turn a style guide into a design pattern library by including engineering requirements for code implementation and an asset library. This can provide a one-stop shop for developers to get both style and implementation information. Generally speaking, code specifications are not the purview of UI/UX designers because there are often many engineering requirements that have nothing to do with the user experience. However, it is often helpful if these details are included, so long as the code structure makes sense and doesn't place undue restrictions on the engineering team's ability to innovate.

7. Analyize & QA: test, fix, rinse, & repeat

Most live projects are never "done". There are always improvements to be made, fixes to apply, and user feedback to consider. The "definition of done" is important for initial project completion, but once the project goes live it's important to allow it to evolve. User testing or bucket testing will allow ongoing analytics to be gathered, and this will allow future informed iterations to happen. During the initial project, however, active user testing allows early design revisions to be made in the interest of staying on target. Bug and defect reporting allows for ongoing code improvements while scrum retrospectives allow the entire team to be aware of their current velocity and where to make process improvements. The show never ends; there's always a sequel.

Of course, every organization has their own particular flavor of UI/UX design. My success has been built upon clear communication, intuitive insight, and a solid understanding of my team's needs. While there are a few wrong ways to do things, there's no one "right" way that is better than all others - it always depends on the needs of the team and organization.

It's interesting to note that most people in the web industry have focused predominately on either design or development, leaving many organizations hunting for the mythical "unicorn" that designs yet still understands code. I have participated in all aspects of the product cycle, from concept inception and PRD/specification to UX design, visual design, front-end development, presentation-layer implementation, user testing, live A/B split or "bucket" testing, and even UX sales. I've worked in the web industry for over 25 years, and one of my greatest strengths is bridging the gap between design and engineering teams, PMs, stakeholders, marketing, clients, and leadership. I encourage you to contact me to learn more about how I can help your organization grow!

Brands Developed

I've developed over 100 independent brands during my career, some of which are listed below. Hover your cursor overTap each of them for a brief description of some of the projects with which I've had the honor of being involved: