Posts describing our processes for user-centered design and usability consulting.

Our company's mission is to design delightful digital experiences for purveyors of joy.

How the Thrill & Create site was built

Recently, I made several big announcements on this blog. One was that the company is now called Thrill & Create LLC, and another is that the company’s new website is now online at AmusementUX.com.

The previous site

The initial work for AmusementUX.com, internally abbreviated AUX, started almost two years ago. The company’s old website, at DalandanConcepts.com (pronounced “dah-LAHN-DAHN”), was the first new website I had designed or developed in about 9 years. (I had built several music-related websites, which are mercifully no longer online, over the 5 years before that – using a very old Mac version of Dreamweaver.) The Dalandan Concepts site was entirely hand-coded HTML and CSS using the now-deprecated 960 grid system. In other words, it was intended to only look good on desktop computers: not a good selling point since I was trying to sell usability consulting services using that site. Last year, I would take part of a weekend to make the site responsive so that it would be at least somewhat usable on mobile devices.

Preparing for Project: Amusement UX

I started planning the site’s replacement almost as soon as I launched it. While researching hundreds of amusement-industry professionals on LinkedIn, I generated a persona spreadsheet. This was relatively preliminary user research compared to what I do now, but this spreadsheet informed the design of the rest of the project.

I initially knew the site as “Dalandan V2” (version 2). I began by developing a desktop-first wireframe and later replaced that with a mobile-first wireframe. Fortunately, I was then busy with client work for a while. Many incoming phone calls during that year, in which people mispronounced “Dalandan” showed me that Dalandan was not a good word to use in the company’s name, whether I had nice pictures of dalandan (a type of fruit which I ate in Southeast Asia) to use for the website or not. Ultimately, what the site needed to sell was design services, not food.

So aside from making the existing site work on mobile devices, buying AmusementUX.com, and identifying a WordPress theme, I did not do any additional work on replacing the company’s site in 2013. I decided to shelve the project until mid-January 2014. Another big decision was to use a daily Scrum process (adapted for a Scrum team of one) in order to design and develop the new site.

Amusement UX: design and development in full swing

The project’s overall structure, including both design and development, consisted of some preparation work, 7 iterations, and 4 spikes.

Iteration 0

This was a brief iteration before work on the Thrill & Create site truly started. I installed a Coming Soon page and wrote some brief copy describing our business. Design work during this phase was fairly minimal.

Iteration 1

During this iteration, I performed my first round of ideation. Hundreds of ideas were then pared down to a much more manageable set that fit the site’s primary personas, and I did sketches and wireframes. My tool throughout the wireframe/prototype process was Axure RP 7. I also wrote preliminary copy for several pages. On a client project, I would have wanted to do a round of testing with users at this point.

At this stage, the homepage was much longer than it is now. Services, blog posts, and the About section were described on the homepage. An initial Process page, not yet reviewed with fellow designers, was already part of the site.

Iteration 2

Iteration 2 fleshed out more of the ideas for the site’s Services page, Process page, and the homepage. The homepage, at this stage, really aimed to establish the site as an authority regarding usability and user experience. It also did more to sell users on responsive design.

By the end of iteration 2, I had made medium-fidelity prototypes of most of the pages in the site. I had also run through Zurb’s Design Triggers list and incorporated many of those ideas. This iteration ended with a round of short usability tests to gauge users’ first impressions of the site.

Iteration 3

The first impression tests told me to revisit the layouts of the homepage and its hero area. I generated 4 hero area ideas and 8 homepage layout ideas and created wireframes and medium-fidelity prototypes of each one.

Spike 3.5

I then ran a survey wherein I paid many users to tell me what homepage layouts provided the strongest, most professional first impression. I chose pairs of ideas to compete against each other in this. Two out of four pairs did not have a clear winner, so I created layout ideas 9 and 10 as hybrids/replacements of these 4 other ideas.

Iteration 4

Iteration 4 incorporated feedback on the hero area surveys and a next round of homepage layout surveys. These resulted in some modifications to the hero area and the homepage. At this point, I ran a set of longer usability tests on the prototype and triaged their feedback. During this stage, I was also working on some business strategy options related to my usability evaluation service offerings.

Iteration 5

The longer usability tests gave me a wealth of valuable feedback. Among other changes, I continued to sketch new ideas for the homepage layout and created new variants of the hero areas. I also created new ideas for the Process and Services page, wrote their copy, and created two more comprehensive prototypes of the Why User Experience Design Instead of Web Design? article. During this stage, I was also making preliminary choices for the site’s typography.

Spike 5.5

Several users in this round of usability testing did not like the color palette which the site was using at that time. Since changing the entire color scheme of a site involves widespread changes and it is not (as of this writing) a simple process in Axure RP, I created a separate sprint spike to work on this. By then, the site was already well into its development process. The Axure RP prototype with the new color scheme gave me a reference for how the site was supposed to look after my code changes.

Iteration 6

Iteration 6 began in early May with adding content to the site, which was still hidden by the Coming Soon template. I started writing a custom CSS file, which eventually grew to well over 4000 lines of code. I spent most of this iteration working on the custom CSS and its associated work items. There was also a support issue with a vendor which took weeks to resolve. It pushed back the launch of the site due to the issue’s severity and the amount of development effort I had to expend to formulate an acceptable solution. Business owners wear many hats, indeed.

Spike 6.5

Spike 6.5, which didn’t meet a standard Scrum definition of a spike as well as I wanted it to, was mainly used for fixing bugs with the site which I had found on mobile devices and for starting trials of the fonts I was going to purchase, in advance of testing the site again with users.

In Spike 6.5, I created Axure prototypes of the homepage’s layout at more widths to show what a working version of the site would look like at those widths as I worked through the bug list.

Iteration 7

At the end of iteration 6.5, I conducted another round of long usability tests, including several tests with other UX designers. This, again, resulted in much valuable feedback.

At this stage I implemented an element collage to ensure a more consistent look and feel across the site. Element collages are now an artifact I produce much earlier in my design process.

I created five new hero area ideas in response to user feedback. The homepage, portfolio items, process page, and services page also received significant changes, for which I created sketches, wireframes, and prototypes.

In development, iteration 7  also involved making sweeping CSS changes because I changed the site’s font pairing in response to user feedback.

Spike 7.5

Spike 7.5 included more mobile bug fixes and many deployment tasks. This spike ended on August 21, 2014, when I soft-opened the site that you see today with a placeholder company name. After more branding surveys, I began the process to officially rename Dalandan Concepts to Thrill & Create.

Next on the agenda

Here on the Thrill & Create site, you may find information about who we are and what projects we are doing. Our Facebook and Twitter pages will have further, more frequent updates from the intersecting worlds of user experience design and amusement.

We would love to work on more user experience design projects and usability evaluations in the amusement space. Please contact us via our contact page or info@amusementux.com.

Daily Scrum for Freelancers

Daily Scrum for freelancers and other teams of one

Thrill & Create does user-centered digital product design for the amusement industry. In other words, we design websites, microsites, apps, and any other digital products with a view toward making these products easy to use and enjoyable for park guests, business partners, and any other prospective buyers in the amusement industry.

Although we work hard not only on design but also on running our business, we also endeavor to work as smart as we can. We regularly see how we can improve our process.

My background in work processes

As a former software engineer for large, mid-sized, and small companies, I was able to ship products successfully in each setting using widely varying processes.

The large company, a multinational corporation which had a team in the hundreds for our project, used a traditional waterfall process. The requirements team handed off their work to the logical design team, which handed theirs to the physical design team. The waterfall proceeded to the development teams and to the test teams before it was turned over to the customer. Meetings and signoffs abounded, and going back to a previous step was largely impossible. To speed up the schedule, the project team was split in half, with each half of the team working on a separate release. While with this company, I started becoming very interested in software development processes and read my first several books on agile.

The mid-sized company used a team in at least 3 states and a spiral development process. They, likewise, had separate people working on each step: requirements, design, development, quality assurance, and integration testing. But the teams staggered their work so that each group could stay one step ahead of the next group.

The small companies used geographically distributed teams and agile processes. I was generally responsible for working on individual features and bug fixes and carrying them through to completion through design, development, initial testing, and supporting quality assurance engineers or systems engineers as they tested my work. Our teams would have daily stand-up meetings and twice-weekly calls with team members in other locations. In each stand-up meeting, members would answer three questions:

  1. What did you work on yesterday? (or on the most recent work day)
  2. What are you working on today?
  3. Are you blocked, or stuck, on anything? (Are you waiting for anything to happen which is keeping you from being able to finish your tasks?)

The advantages of agile

First published in 2001, the Agile Manifesto lists 4 core tenets:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

While agile teams still value the items on the right, they value the items on the left more. Agile processes allow companies – particularly smaller companies – to respond quickly when their clients want something changed. They also tend to minimize, but not eliminate, paperwork.

1. You spend more time doing design, development, or testing.

I was surprised at how little time I spent writing code at software development companies that used a waterfall process. Other team members and I spent many weeks between development iterations writing comprehensive documentation and waiting for other groups in the project team to hand off their deliverables to us. In the agile shops, I wrote code nearly every day.

Designers in an agile project can spend more time designing. Developers can spend more time developing. And testers can spend more time testing. They all become better at their crafts faster. No more sitting around for weeks with nothing to do while you wait for another group to get their work done. There is generally a lot less waste in agile processes.

What that means for you: Agile gives us more time to master user experience design, so that each new site, app, or other digital product we ship is noticeably much better than the previous one. It allows us to become UX experts faster.

2. A product’s users are more likely to end up with a product that they want.

The Lean Startup movement emphasizes the notion of the minimum viable product (MVP). The MVP has only the features that allow a product to be launched. Typically, the MVP will be deployed to only some of your customers: those who are likely to be more forgiving and more willing to give helpful feedback on the product. With fewer features to work on, the project team can focus on making each feature exactly right.

MVP helps companies to understand what customers want more quickly and to focus on developing the right product ideas for serving them best. Later releases of the products can include more features and a wider release.

What that means for you: You’ll know very early in our design process what your users think of our designs. We start our testing with users far before the first release of a product. Many products can be tested with users starting with as little as a sketch. We will use test users who represent your target market well (verified with user research), so that we will take your digital products to market with greater certainty that they will want them.

3. You can ship (and make money from your product) sooner.

This is tied to the minimum viable product (MVP) strategy from the previous point. Because an MVP has fewer features, it does not require as much time to design or develop. This allows the product to be released and sold (or used to help sell other products) much sooner.

Scrum, a widely used agile method which I have also implemented at Thrill & Create, organizes work into a product backlog. The backlog is a list of requirements (features, bug fixes, user test comments, non-functional requirements) that the project team maintains. After the product owner identifies which items need to be in a shipped product, the team needs to work through items on the backlog in order to be able to ship the product. Story points help us to estimate how long everything will take.

What this means for you: If your website, app, or other digital product does not need to be launched in an all-at-once fashion, we can release it in stages. This helps provide you with a fast return on your investment before our team is even done with design and development.

4. Problems are easier to identify and fix early.

Design and development are not exact sciences. User research can help us anticipate what users will want. However, it doesn’t absolutely ensure a correct design. And many software development projects encounter problems that require extensive rework to fix properly.

Fortunately, the Agile Manifesto emphasizes working software and customer collaboration. At a development level, this means that as early in the process as possible, there is always a version of the product that they can ship to customers at a moment’s notice. That version keeps receiving updates as the developers continue to deliver work. At a design level, we test designs with users at many stages to identify problems with their usability and validate which design directions are correct. This allows us to avoid wasting budget developing solutions that do not work.

What that means for you: Your budget will be used more effectively because we won’t spend it going far down the wrong path in our designs.

5. It is easier to allow customers and users to change the product without having the product ship late.

One of the main reasons why agile processes were developed was that waterfall processes respond to change poorly. Waterfall projects often use slow, involved approval processes in order to have changes approved. Teams often have to work at an unsustainable pace in order to ship changes without slipping the project schedule – if that is even possible.

Agile – and in particular, Scrum’s story point system – makes responding to changes easier. Scrum iterations have a fixed duration and a fixed number of story points or hours available. With a fixed timeline, we can use these estimated task durations to determine what makes it into each sprint: new features, bug fixes, testing, and any other work items. Changes that happen often result in lower-priority tasks being removed from the sprint and either deferred to a later sprint or removed from the project. The ship date is only pushed back if the changes do not result in existing tasks being removed from the project.

What that means for you: While we are the designers, we collaborate with you consistently to make sure that you are getting what you and your users need. We are able to accommodate changes in a project in a way that does not jeopardize ship dates as long as our overall project scope remains the same.

How Thrill & Create implements Scrum

At Thrill & Create, we have had different ways of working with our project teams.

When I worked on the Coaster Crew projects, I had one primary and one secondary point of contact with the other Coaster Crew staff. My main point of contact was their webmaster, who also handles the back-end development for their sites. I sent him a weekly status email which detailed what I was working on and whether I was blocked on anything. On tasks that required more involvement from him, we would communicate more frequently via email or Facebook chat. I handled project management and usability test triage using an Excel spreadsheet, which was mainly for my reference.

My secondary point of contact with The Coaster Crew was their vice president of membership. The webmaster and I interfaced with him for more directional-level decisions and budget approvals. Beyond this, I was also able to ask questions or post comments for the rest of The Coaster Crew’s staff to answer.

When I worked on a redesign for a local nonprofit, I initially had a project team consisting of myself as UX designer/PM, a graphic designer, a developer, and an idea guy. We met weekly over dinner to discuss our project and move the project forward. This project was done in a more waterfall-like setting. Due to multiple factors beyond our control, I ended up completing the development myself using a daily to-do list for project management.

I decided to make the rebrand from Dalandan Concepts (pronounced “dah-LAHN-DAHN”) to Thrill & Create a purer application of Scrum processes.

But how do you do daily stand-up meetings as a team of one?

Partway into the project, I created a Daily Scrum spreadsheet with the following columns:

  • Day of week and date
  • What I did yesterday
  • What I still need to do from yesterday (if anything)
  • What I’m doing today
  • What my main project for the day is
  • What iteration I am on in my main project
  • What my second and third projects are (if any)
  • Am I blocked on anything?

I’ve added an entry to this spreadsheet each day since then. Typically, I begin the day by checking my email and doing any other administrative tasks unrelated to my main project. After a break for breakfast, I fill out my Daily Scrum spreadsheet for the day and get into my main list of tasks.

Often, my tasks for the day in Daily Scrum come from my master to-do list. This makes the Daily Scrum process very easy.

Early iterations would be focused on preliminary design tasks, such as user research, persona generation, brainstorming, and sketching. After that, my iterations would usually take the following format:

  • Work on design for items in the iteration
  • Work on development for items in the iteration (Note: For multi-person teams, UX design authors have advised making the design team stay 1-2 sprints ahead of the development team)
  • Draft a list of tasks for user testers
  • Run a round of user testing
  • Write down feedback from each tester, including some metadata indicating which users were closer to our target persona
  • Triage feedback from each tester based on the item’s priority, severity, and level of effort. (Items that multiple users cited and items cited by users with characteristics closest to our target personas’ were given a higher priority.)
  • Determine what would go into the next iteration.

However, my role for the Thrill & Create site was bigger than design. I was also responsible for the site’s development. This made estimation more of a challenge. Several iterations had spikes, shorter timeboxed periods for researching concepts or creating a simple prototype. (Some spikes, such as the ones I did, do result in more features and bug fixes being delivered for the product.) This is why my Daily Scrum spreadsheet has some days listed as Iteration 3.5, 5.5, 6.5 and 7.5.

I also use task breakdowns fairly extensively in estimating the duration of a task. Task breakdowns enable more accurate estimates because they force thinking about the details of finishing a task. Agile methodologies encourage further breakdown of any task estimated to take longer than two days. Incidentally, my biggest lesson learned from the Coaster Crew launch was to not assume that migrating the site from a prototype to WordPress was a short task. Initially, I had estimated it to take 3 days, but the extensive development required for the migration added weeks of work to the project.

The way I do triaging is somewhat different from the story points method in classic Scrum. With the Thrill & Create site, I assigned the effort of work items on a more relative scale. My spreadsheet, then, had columns for priority, severity, effort, and priority times effort. That helped guide me through selecting work items to include in sprints.

The priority and severity scales I use are based on several I found in this Interaction Design Association (IxDA) forum thread. Thank you to Jim Drew for these scales:

  • Severity: Critical: a crash or data loss; users are blocked unless they restart the app or reload the webpage. UX issues rarely reach this level.
  • Severity: High: A major feature is broken and can’t be used fully, or a minor feature is either too broken to use at all or not present
  • Severity: Medium: A major feature can’t be used fully, a minor feature is blocked, or a feature is broken but has a workaround.
  • Severity: Low: The problem doesn’t affect (or only lightly affects) users’ ability to use a feature. An example of this would be poor message wording, or color contrast that meets WCAG AA but not WCAG AAA.

The priority scales I use are based on the following. I adjust them according to how many users are reporting a problem and how close those users are to our target persona:

  • Priority: Critical: This needs to be fixed in this iteration, or other items (priority high or medium) cannot be addressed until a fix for this one is complete.
  • Priority: High: We need to fix this item in this iteration, or at least before we ship the next release.
  • Priority: Medium: We would like to address this item in this iteration or release, but we might not get to it.
  • Priority: Low: We are likely to not do this work item; we only have it in the spreadsheet so that we can track the issue.

As a bonus, here is how I scaled the required effort for a task for the Thrill & Create site:

  • Effort: Extreme: Significant increase to the project scope. Feature is either impossible to build or would require significant development effort or substantial budget/travel to build. For example, one tester on the Thrill & Create site did not like the fonts in several portfolio items. To change this honestly, I would have had to essentially redesign the typography of sites I had already delivered to other clients.
  • Effort: Very High: Bugs that are probably fixable but have a great deal of uncertainty and/or require testing in many configurations. New features that require a great deal of thought and care and/or a full design process to implement properly. For example, comments concerning the overall mood of a site require a thorough review of many aspects of a site to identify the best solution for changing the site’s mood.
  • Effort: High: The work item requires extensive, well-thought-out changes to implement properly and may require new sketches, wireframes, and/or prototypes. For example, when we are asked to change a site’s color scheme, we research new color schemes and test them out in prototypes. High effort could also mean that a bug is affecting different kinds of devices in different ways. For example, the How Can We Help? buttons on the Thrill & Create homepage were displaying unusual behavior around some breakpoints and had to be tested extensively on multiple devices since they essentially required a partial rewrite of a grid system.
  • Effort: Medium: The fix seems simple, but dependencies make it so that we have to make sure it doesn’t break anything else in the site. For example, if the site’s grid system on one page needs more padding at tablet widths, we need to make sure that changing it will not cause undesirable effects on other pages.
  • Effort: Low: Bugs that I already know how to fix when I see them or features that only require a few lines of code to implement. For example, during the Thrill & Create site’s development, the text on the Send Message button was too small. This was relatively high priority but a very simple fix.

Tips for freelancers and teams of one who are considering implementing Daily Scrum

Maintain a Daily Scrum spreadsheet which says what your current projects are, what you did on the previous work day, what you are doing today, if there was anything from yesterday you didn’t get to do, and if there is anything blocking you from finishing today’s tasks.

  • Make it daily: Set a reminder every morning (on work days) to update your Daily Scrum spreadsheet
  • Consistency: Don’t worry if you miss a day. Just make sure you get back to it.
  • Billing: If you do not bill hourly or use value pricing, bill in iterations.
  • Schedule: Timebox the length of an iteration. In other words, if you say at the beginning that an iteration lasts for 3 weeks, keep the length of an iteration at 3 weeks. Don’t go over.
  • Clear communication: Especially if you are remote, always be clear with your clients on what you are working on and whether or not you are blocked on anything.
  • Collaborate: Make sure to collaborate with your clients, especially with your main point of contact. “Here’s your assignment, now go do it and give it back to me when you’re done” is not a way of thinking that Scrum encourages.
  • Minify?: The optimal size for a Scrum team is 5-9 people. If your team has 1-3 people, consider a process with less overhead by replacing some of the meetings with less formal sessions.
  • Remember what it’s for: Use it to stay accountable (to yourself and your client), productive (the point of any good work process), and happy (probably one of your reasons for being in business for yourself).
Partial results of a usability evaluation for the Coaster Crew fansites, prior to redesign work.

Our Process: Usability consulting

My earlier article about my user experience design process gave definitions of some of the subdisciplines within UX, such as information architecture, interaction design, and visual design.  Usability consulting touches upon all three from a more academic point of view.

I’ve evaluated website usability for over 50 clients, including repeat business regarding different features of their sites for several of them.  In usability consulting, I take a deep-dive approach tailored to each client, to provide more specific feedback.

Usability consultants take some criticism for being critical about every little thing.  While it’s important to identify all of the places where your site can be improved so that your in-house designers (or I) can fix them, I also want to identify areas where I think your site performs well.  As a software developer, I was part of several code reviews of large features that went on for hours and given me a whole slew of things to change, with no positive feedback.  I don’t want to do that to you.

A list of usability consulting recommendations from me could involve very specific recommendations, such as “your checkout button needs to be __% bigger” or “it takes too long to find this button to click on it”.  It could also be much more general feedback like “change the background so that the text is easier to read”.

I would begin this sort of project by researching your target audience and developing personas – like the personas list I create for a new design project.  If you already have personas, I would make sure they address all areas that personas need to address (at minimum: demographics, role, main points, goals, frustrations, and some biographical details).

Then, I would ask you what areas you want me to target most.  I want you to get the best value for your budget in this study, while also making sure that your site gets the best results it can.

From there, I could draft a list of tasks (and/or use a list from you) to go through in using your site.  I’d go through them and also recommend usability tests with a group of customers that represents an accurate cross-section of your actual and/or target audience.  The goal in this is to find out what’s working in your site and what isn’t – for your customers.

At the same time, I would go through your site in much finer detail with a lengthy evaluation checklist.  In this step, I would identify underlying problems that testers might not be able to articulate within the few minutes that they would normally spend on your site – but things that they would still notice nonetheless.  This checklist can give your web developer or development team a very specific list of what they will need to change (or what they need to pay attention to when they receive specifications for a redesign).

Ultimately, I would also give you sketches or wireframes for a suggested redesign.  You could work from this directly, hire me for follow-on work to complete the redesign, or send it to another contractor for him or her to flesh out further.

A word on developers and “the user”

If you hire anyone for a redesign, hire a designer or design company that will employ a user-centered design process – and find out from them what that process is before you hire.  Make sure that they really practice it and don’t treat it like a buzzword to cover up a developer-centered design process.  Look for them to use regular cycles of user testing, rely on other people in your company and audience (rather than starting the project and saying, “Thanks, I’ll get back to you in a few months when the design is done”), design for every possible condition, and take your company’s goals seriously in their designs.  If they don’t do these things, among others, they are not user experience designers.

Many developers talk about “the user” as though they know who this mythical “user” is.  However, they have no contact with, and little understanding of, the people who will actually use your site.  Thus, they may have good intentions but still create a site that doesn’t meet your users’ needs and does cost you sales and customers.  One development book, 97 Things Every Programmer Should Know, has a chapter called “You Are Not The User” – because many developers don’t know that experientially.

A sample task breakdown

Task breakdowns need to be customized to your site or app.  Here is one that I proposed for evaluating the usability of a purchasing path.

Customer Analysis & Personas:

  • Work with you to analyze your site’s customers and target audience.
  • Develop personas with the following, based on your user base:
    • Demographics
    • Scenarios
    • Goals
    • Frustrations
    • Brief biographical details
  • Adapt the personas’ list of tasks into a list of tasks and feedback questions for usability testing (see below).
  • Milestone/Deliverable: Personas spreadsheet.

Usability evaluation based on your personas:

Usability testing

  • Perform a cognitive walkthrough of the personas’ common tasks
  • Recruit usability testers representing each persona category (your budget and schedule determine the group size)
  • Usability testing with recruited testers, using the task list above.
  • Conduct a usability review based on your site and user test feedback
  • Milestone/Deliverable: Results of cognitive walkthrough and summary of usability test findings

Accessibility testing

  • Run an accessibility checker for your site overall or for the part of the site in question
  • Perform a manual accessibility evaluation using Web Content Accessibility Group (WCAG) 2.0 guidelines
  • Milestone/Deliverable: Recommendations for allowing you to appeal to a broader base of users

Purchasing path evaluation

  • Evaluate your site’s process to help users find the products that they want to buy and make recommendations for helping you get more people to add items to their carts
  • Evaluate your checkout process to help you move your users forward in the checkout process and get them to check out
  • Preliminary redesign (mockup) for new purchasing path:
  • Develop quick mockups of your purchasing path.  (These would not be detailed, but could serve as a starting point for follow-on redesign work.)
  • Milestone/Deliverable: New purchasing path mockup images.

Next steps

Our final deliverables would include our usability recommendations and reviews. If a redesign is desired based on the above recommendations, we would then write a proposal for that redesign work.

Further reading

This is a partial list of books that have taught me about usability for applications and the internet.

Screenshot showing our redesign for the SFAFansite (Six Flags America Fansite) homepage.

Our Process: User experience design

Note: We originally published this post in 2012 on our previous company site. There have been some changes to our process since then, though this article fleshes out some steps that we use in our process today. Our current Process page supersedes any steps in this process which may conflict with it.

If you compare the rates for freelance UX designers against the rates for freelance web designers, you may see quite a disparity.  Some people ask, “Isn’t ‘user experience design’ just another way to say ‘web design’?  Isn’t it just a ploy to charge us more money?”

No.  ”Web design” can take on many different definitions:

Some people equate “web design” with “web development”.  They want to code up cool features that haven’t been done before, and most of them don’t care a great deal how it looks; it’s “somebody else’s problem”.  Sites can turn over 100% like Microsoft.com from 1994 to 1995.  While sites like this would look terrible by our standards today, they were really groundbreaking in 1994.

Some people equate “web design” with “graphic design”.  They want the site to look as cool as possible.  In the early 2000s, there was a trend toward hidden navigation menus.  You had to run your mouse over a series of dots to find out what the navigation options were.  It looked minimalistic and flashy at the same time, but it was hardly user-friendly.  It made users think about where to go next instead of thinking about purchasing a product.  Still, without graphic designers’ help, the web might still look as it did in the 1990s – table-heavy, frame-heavy, and much more interested in function than in fashion.

User experience designers say that both of these camps have made valuable contributions to the web and applications, but they are both wrong in what they value.  Neither developers who only focus on development nor visual designers who only focus on visual design are meeting the needs of the actual audience.  To use an amusement analogy, their site may be like a roller coaster that breaks some records (great features) and has excellent theming (great visual design) but gives people severe headaches (bad user experience).  To make a successful ride that doesn’t put people in pain, you have to understand your riders – their physical dimensions, their health, how they would react to different maneuvers – and design the ride accordingly.

So my work as a user experience designer involves this:

  1. Usability expert
  2. User researcher
  3. Information architect
  4. Interaction designer
  5. Visual designer
  6. Prototyper
  7. User tester

Usability expert

I have to understand, academically, what makes an interface usable.  Certain tools in my toolbox are job skills that I can apply to any project.  I took a class on human-computer interaction in college and applied my knowledge in it as a user interface developer for several small companies.  And you’re welcome to see what usability books I’ve been reading if we are connected on LinkedIn.

This approach has to be much more than academic – which is why I include the other roles below.

I will write another article in the near future about my usability consulting process, so the rest of this article will concentrate on design.

User researcher

I have to understand your specific customer base, both those who you are currently targeting and those who you plan to target.  Amusement companies have to understand which segment of the population they are targeting with a specific ride.  Building a gigacoaster in a park for small children doesn’t make sense.

Though, admittedly, we don’t have to know much about physics, UX practitioners have more than age, height, and health to consider.  We have to consider demographic information such as nationality, ethnicity, and location.  This is even more important for cross-cultural projects and companies that target a global audience.  I study international UX as part of my research to help accomplish this.  In addition to demographic data, we have to think about how often (and how well) they use computers and mobile devices and what their goals and frustrations are.  This makes my research involve psychology as much as computer science, sociology, and business.

The general categories of users fuel what the UX world terms personas.  The personas get names and descriptions and stand in for people during much of the design process.  They also must accurately represent the entire user base; I can’t choose who my site will cater to and say that I accurately advocate for users.  I write a persona worksheet for every new project.  The one for the upcoming redesign of my company’s website has 14 personas and 27 rows of information for each.

Information architect

Information architecture on the Web boils down to how your site is laid out and how individual pages are laid out.  In short, information architects are like librarians for the internet.  They deal just with the information, not with the visual presentation.

In the early stages, IA work can involve pencil-and-paper sketches.  Ultimately, IAs produce wireframes that provide the structure for each page (or type of page) that will ultimately be delivered.  I produce wireframes using Axure, an industry-leading wireframing and prototyping tool.  Anyone, whether they have Axure or not, can view these wireframes in their web browsers.

Overall site layout deals with your site’s navigation options, site map, site index, and any layout rules that apply to any page.  It also involves helping your users find the information they are looking for on your site.  Even the smallest sites must have clear ways to find information.  This necessity only scales up with the size of your site.  In e-commerce, if users are confused while they are trying to find a product, they will most likely give up and go to another site.  For that reason, well thought-out navigation menus and search are paramount in building an effective website.

Individual page layout primarily involves presenting your information in a way that is aesthetically pleasing, user-friendly, accessible, and findable.  When I work on HTML prototypes (as I will describe later), I test them for compliance with international accessibility standards so that your site will reach the largest audience possible.  The information on a page needs to not compete inappropriately for your users’ attention.  And the layout of each individual page needs to support easy site maintenance.

If you run multiple websites or microsites, information architects can help you unify your brand.  IA certainly plays a role in determining how users access the information in a large site that is relevant to them.

Relatively few companies employ full-time information architects for their websites.  Many smaller sites rely on part-time consultants who specialize in information architecture.

Interaction designer

Interaction design involves both the form and behavior of your website or app.  It deals with making sure that your site meets the needs of its users.  Thus, it involves researching your current customer base and your targeted new customers.  Personas, as I described earlier, play a central role in interaction design.

Amusement and tourism companies have a great need for triggering their users’ emotions.  Their websites play a very strong role in this.  Sally Corporation uses their website to convey newness, nostalgia, realism, and technological breakthroughs.  Loro Parque uses their backgrounds and a “TICKETS” callout toward the top of each page to sell their park as a ticket to fun.  And NewZealand.com uses clear callouts in each category page to take its visitors on a journey of discovery.

Psychologically, interaction design also involves eliminating distractions so that users can focus on what matters.  Amusement and tourism companies can draw on this by testing their sales processes with users and then streamlining it.

Visual designer

Visual design encompasses many subdisciplines, including advertising, marketing, copywriting, infographics, and visual arts.  These designers can work in both print and online formats.  My visual design work focuses mainly on typography and color schemes.

During the prototyping process, a visual designer who has been given wireframes has to understand which direction to go to produce the best-looking result.  Visual designers work within organizations’ brand guidelines and integrate their skills into designing appealing interfaces and experiences.  Their role strongly influences your users’ perception of your brand.

Prototyper

Prototypes allow me to build early designs of your site without the huge additional cost of development.  Wireframes are an earlier stage of prototyping, and even at that stage I can still start understanding how your site will work with its users.

Prototypes are interactive; users can start seeing how the actual site will work, without the up-front development work.  They can focus horizontally to show your site’s overall structure, vertically to show how one feature of your site (such as a ticket-buying process) would work from start to finish, or a combination of the two.

A low-fidelity prototype, also called a mockup, could involve the paper sketches that I mentioned previously with information architecture.  There, we can start determining how pages interact on a basic level.  Interaction at this level is minimal, and it definitely does not look like a finished product yet.  However, we can use this stage to help guide the future direction of the project.

A medium-fidelity prototype includes more interaction and starts involving more graphics.  Since they are made on a computer, changing them involves more risk – but still not nearly as much risk as making these changes after development.  Changes at this level are still relatively quick, and your actual end users have more confidence testing this kind of prototype since it looks more like an actual website or app to them.

A high-fidelity prototype, in essence, appears as the finished site or app will.  It involves any and all graphics or animation that the site is expected to have, so graphic designers and animators have invested much more time and effort by this stage.  There are two major caveats regarding this stage:

  • Making additional major changes could cost a great deal of time and effort and cause delivery dates to slip.
  • People who see or test a high-fidelity prototype tend to think the site is done already.  In fact, the code that drives prototypes is not yet ready to be used in the real world yet.  A developer or team of developers needs to make sure that the site will still withstand the rigors of everyday use without going down.

I like to use Adobe Dreamweaver for high-fidelity, HTML/CSS prototypes because that starts pushing the project toward development.  From there, I can turn over templates that already emphasize accessibility to web development specialists.

User tester

The user research doesn’t stop when the persona spreadsheet is done.  True user-centered design involves at least several rounds of usability testing throughout a project.  If I did not both consider your business objectives and involve users, I would not be a true UX designer.

When we know what pages should be part of the site, I would arrange one or more card sort tests via Optimal Workshop to help determine how these pages should be categorized.  Their OptimalSort tool automatically aggregates everyone’s responses and tells us which layout(s) make the most sense to your audience.

Layouts of individual pages and interactions between pages would be ready to test with your audience after I have completed the wireframe.  Then more rounds of testing would take place on the prototype, primarily on its interaction and visual design, to ensure that it meets users’ needs.  All of this testing can be done remotely.

Axure has a sharing server which lets me share wireframes and prototypes with your potential users in a password-protected manner – so that only the testers will see your site or app before it is live.  I encourage you to give your testers non-disclosure agreements when they participate in these studies.

User testers typically are compensated.  If not with money, you could give them gift cards, merchandise, or some other reward.  For an amusement park, I’d suggest letting people do a test or two in exchange for their choice of a free first-in-line pass, a free or heavily discounted ticket, or free lunch and dinner.

Where I would hire outside contractors

I would typically hire outside contractors (who you would also approve) early in the project to do the following:

  • Illustration / animation / complicated graphic design – I can edit photos in PhotoShop, Fireworks, and GIMP, and determine color schemes and fonts.
  • Development – I can make prototypes with HTML5 and CSS3.
  • Web hosting – if you need a web host.
  • Content management system (CMS) installation and management

I believe that if I concentrate on UX and hire other people for other specialties, you will get the best value and the best results.  If you have artists or developers in-house, even better; I can work with them!

Also, I do not work on clones of existing sites or apps because I believe that each of my clients deserves a site or app that is uniquely theirs.  Cloning the hard work of others and charging you for it is stealing.  Having said that, design patterns are quite common and accepted in the UX design community, and I do find working with those important to help myself work more efficiently and to give you work products that have been accepted by the design community at large.

My typical task breakdown

So, with all of the above roles in mind, my task breakdown for your project could look like this:

Existing design

  • Review and evaluate functional specs
  • Review and evaluate existing design, if applicable
  • Current production version
  • Design artifacts if available

User research

  • Analyzing your prospective customers
  • Interviewing stakeholders, if possible
  • Developing personas
  • Adapt the personas’ tasks into a list of tasks and feedback questions to use for usability testing (see below)
  • Deliverable/Milestone: Spreadsheet of personas

Wireframe

  • Develop look and feel (new wireframe) using Axure
  • Brainstorming based on the personas
  • Idea selection based on which ideas will best fulfill the specifications and are most practical to implement.
  • Review ideas with client
  • Start on a wireframe.
  • Deliverables/Milestones: Excel spreadsheet listing ideas generated during brainstorming and selected during idea selection.
  • Create the wireframes:
  • App navigation (site-level information architecture)
  • Page-level information architecture
  • Run a remote card-sorting test with testers in your product’s target demographic.
  • Deliverable: Completed wireframes.

Prototype

  • Create higher-fidelity prototype using Axure:
  • Visual design
  • Display font face and sizes
  • Copy font face and sizes
  • Interactions between pages
  • Validation logic and error checking for the prototype, depending on requirements
  • Determine other interface details: Task breakdown depends on what other interface details are needed.

Functional testing of the prototype

Usability testing

  • Have a group of testers complete the tasks in the list of tasks developed earlier. They will answer the feedback questions after the test.
  • Deliverables: User testers’ videos and written reviews.
  • Review user feedback with you to determine what changes we should incorporate into the final deliverable.
  • If any changes are required, incorporate users’ feedback into new versions of the wireframes (if necessary) and prototypes.
  • Iterate on usability testing and incorporating feedback until you are satisfied with the result.
  • Final deliverables: The prototype that has passed usability testing and reviews, along with intermediate versions used for usability testing.

The exact tasks depend on what services I am performing for you, and the durations are different for each project.

Further reading

If you are a beginning UX practitioner or would like to understand how UX works further, here are some books and blogs I’ve been reading on these topics:

Information architecture: Information Architecture for the World Wide Web by Peter Morville and Louis Rosenfeld.

Usability and prototyping: Usability First blog.

Interaction design: The Inmates Are Running the Asylum by Alan Cooper.  The title refers to a conference speech that Alan gave, when he explained that most business executives have left design decisions for software in the hands of programmers instead of designers.

UX project management: A Project Guide to UX Design by Ross Unger and Carolyn Chandler.