My UX project workflow

From small device to very large screens

My experience in starting a project, my role, and my approach throughout the process.

My Role

Gather or create user requirements from the client, and end-users.

Conduct Tree testing, Card Sorting, and Informal User Testing.

Create usability research documentation, such as user flows, personas, user stories, workflows

Design wireframes that are the basis for the visual design.

Create mockups based on the wireframes when needed.

Create interactive prototypes for testing and communicating the design to the team and client.

Write functional and design annotations for the wireframes for visual design and development teams.

Starting a Project

When a project is to be started, I need to determine what the design will live in. Meaning, is it on an Tablet, Phone, touch screen or not, and so on. Will it have internet access or is it a stand alone product...

If this will be up on a wall or a tablet kiosk. This is where these requirements will need to be determined. Of course, in a real world project, anything can and often does change. So being adaptable is important.

After that is understood, next is who the intended audience will be. How can those users be segmented?

Next, I try and determine what the core goals of the design are. Is it to communicate a message, is it have a user interact? Is the goal to gather information from a user?

There is usually a project brief, or something outlining the project. I talk with project managers, hear what has been discussed with the client. A PM usually is more focused on the timelines than functionality and other technical details. The timeline usually dictates how to approach a project.

If I have more time, I like to spend it on what I call pre-production. Meaning, I am creating documentation that helps understand the audience, their goals, and create a experience journey map to understand and map out the user's journey from start to finish.

If more time is available, I'll then take that and segment it out for every user. This is a lot of work that will pay off later on, so I do what I can with the time available. Having access to users helps considerably.

Because many projects are a rush, and have tight timetables, when I have extra time, or when I know I will be building many similar designs, I create re-usable templates. This is a big time saver, and that time can be spent on other areas that can have a big impact.

With these building blocks I can start to piece together a sitemap. This sitemap starts as a simple page by page outline of the site, and gradually evolves to describe the overall design and to describe what content is in each page if this is needed by the team.

A sitemap will include screen heirarchy. What screens are the top level, which are children of those. Once this is figured out, if there are use-cases that need to be optimised. How do we want the user to progress through the site/app? Is there a requirement that certain information needs to be accessible in 2 actions? At this stage it is the best place to impliment this.

If the project is to be a responsive website, the breakpoints need to be determined and explained so that development understands that effort requirement.

A card sorting exercise may be conducted to understand how the users organize the content in their mind, this may tell us that we need to adapt to their view. Often times the content is strictly determined by the client and those more familiar with the subject matter.

A great follow up to to card sorting is a tree testing exercise. This helps to confirm the results of the card sorting. This avoids the problem is users creating a pile for items that are not easily categorized.

Starting the Wireframes

Now that the core requirements have been discussed and all team members understand what is involved, I can begin designing screens. While the sitemap may have some gaps in it, or may have changes made to it, at least everyone understands the big picture and where we're at.

I have a general idea how much space will be needed for the navigation, this will help answer what navigation options we have to work with. If we have 10 sections, we may need to reoganize somethings, and do a content audit and evaluation.

Filling in the content

Depending on where the content of the site/app has been determined, I will use Lorem Ipsum to fill out the content. Block out where graphics need to go. And, as described in the sitemap, I will differentiate the utility navigation from the main navigation. If there is secondary/local navigation, this will also be inserted into the design.

With these designs, they are presented to the team, we can figure out if this meets everyones expectations. Notes are taken, and the design is updated with those changes.

Adding photos, colors and fonts at this stage will lead to a lot of discussions that should be saved until later. It's like talking about what spices and plate decorations when we haven't even figured out what we're cooking and what equipment we're going to cook it on.

Let's first figure out that we're going to have the main navigation up there, utility links up here, and content will run down the page down here.

I think of pages like templates. The homepage is a template, a search results page is another template. A category page is a template, a product detail page is another.

Having spent years building websites, I understand that this is how development is thinking of it. How many have unique layout and functionality. If there are 20 articles in the same category, then more than likely, it is 1 template. If one has a video, interactivity, these are seperate templates.

Depending on where the content of the site/app has been determined, I will use Lorem Ipsum to fill out the content. Block out where graphics need to go. And, as described in the sitemap, I will differentiate the utility navigation from the main navigation. If there is secondary/local navigation, this will also be inserted into the design.

With these designs, they are presented to the team, we can figure out if this meets everyones expectations. Notes are taken, and the design is updated with those changes.

When options are wanted to present to decision makers for something like, navigation methods, I present options with pros and cons. Once a decision is made, we can move forward.

Communicating with the other departments

At this stage it is important to include development into the conversations so that they can give an estimate on the effort in building this website/app/kiosk.

If all goes well, these wireframes can be shown to a visual designer who can then start creating mockups for these wires. These will help in getting buy-in from the client, and other stakeholders.

Communicating with Development

If the project is a responsive website, we need to determine the breakpoints supported. Will this be phone and desktop? Will this support touch displays and devices? This has an affect on the size of interactive elements.

If the project is a tablet, testing on a tablet is very helpful. Fortunately the wires being built can easily be turned into a prototype using AXURE RP. Text fields, drop down menus, side navigation, lightbox functionality. It's very helpful when showing during a presentation.

If the wireframes are needed to be shown in a way to reduce possible confusion, then it can be shared as a PDF.

At this point annotating the wireframes will start. To avoid confusion and lost time, I write out and describe thoroughly the expected functionality of the design.

Iterative Testing

There is always a benefit to come from testing a design to understand how it is used and find things that we didn't expect.

This becomes more important when the application is not a very common. If it is both a custom application on a custom display, the interactions need to be as simple as needed to accomplish the goals.

If user testing is not able to be done because of either time or the nature of the content, I rely on my experience designing many websites for different devices over the years. If it is a custom application, I rely on design priciples when they fit the context.

Refining the Design

Once the wires have been handed to visual design, they will begin to produce the mockups to be reviewed by the team. This is an important point in the process, as the intentions and reasons for the user interface should be kept intact.

A visual designer may interpret the intent differently and this will lead to miscommunications. If however there is a logical reason for the change that produces a better product, then that is more than enough to make a change.

The purpose of wireframes is to serve as an early draft of a design and are not intended to be rigidly set in stone.

Communicating the design to development

Development of course should be included early, but at some point they need to understand how this application/website will work. Not just how it will work, but every possible state and scenario.

Having spent some time doing web development (though I wouldn't call myself a developer), I understand that although something may be the case 99% of the time, that 1% situation needs to be built, so that application doesn't break.

With that said, I create very readable and thorough annotations for my wireframes. This comes in handy in case the development team is off-shore and they begin their day after we leave. No impediments halting the development.

Client Pushback

I go by the philosophy of correcting early on in the process. Get it wrong early and check back often.

With that, I like to show the design as soon as something substantial is there to show. I also like to show different options on things like, main navigation, content layout, and the flow of the site.

Lessons learned

  1. Every project worked on leads to some lessons learned. Sometimes it is working on a new device, other times the content being displayed is different.
  2. For example, designing an iCVA carries with it unique requirements. There is an existing interface that goes atop the application being built into it. Users are accustomed to interacting with these applications a certain way. Improvements some times need to introduced over time.
  3. Other times it is working with a new team or team members. It is very much a team effort, so being available or voicing thoughts is a critical part of launching a product.
  4. If the project is something familiar and something I have designed many times, I try and optimize my workflow or improve on my presentation. If I am working with different software than I'm used to, that expands my skillset and flexibility.

Thank you for reading. Related to this is my UX Strategy. I go over at a higher level my goals and approach in designing a user's experience.