I’ve written previous posts about how I use Balsamiq Mockups to create wireframes and prototypes, and my methods for usability testing. But these are parts of a bigger process — getting from an idea to a finished website, application or software product.
My UX Method
When a new client engages me to work with them on a new design (or redesign) project, they are keen to know “What method did you use?”. While the components / tasks are flexible, the process is consistent:
Goal: To listen, observe and think
On website or application projects, participants are usually eager to get stuck in — to start building something — as soon as possible.
Many believe the way to get a “minimal viable product” is to start writing code on day one. Experience has taught me otherwise. The analogy is painting a watercolour — the wise artist knows, of course, that more time arranging the fruit optimally leads to less grappling with their masterpiece weeks later.
Before designing, I will undertake at least one, often several of the following research tasks.
- Client workshops (continues into the next phase)
- Stakeholder interviews
- Contextual enquiry / Field research
- Analytics (in practice, almost always Google analytics)
- A/B testing
- Competitor Analysis
- Thinking (not to be underestimated)
- Task analysis
- User journeys
- Card sorting
Some of these tasks, like storyboards and card sorting, I undertake only occasionally — it depends on the individual project (card sorting, for example, is useful for sites with large information architecture problems). I am always open to new tasks (or “tools”) that fit in with the general process.
2. Workshops and Early Sketches
Goal: Define the product requirements with the client
I usually hold a series of workshops on the client site. The participants are a small group of key internal stakeholders, including a development / engineering team leader.
Often the client does not know precisely what they want. Part of my job, at this stage, is to tease out and challenge their loosely-formed ideas.
Throughout the client workshops , and I continue listening, but now I am able to inform the client about what I have discovered based on the research I am undertaking.
During these workshops I will develop some early-stages sketches on a flipchart or whiteboard, and the stakeholders present will all pitch in with their ideas. We effectively develop the initial wireframes — a visual representation of the product requirements — together.
Photos of Everything
I take a photo of these whiteboard pages on my phone, along with other interesting online artefacts that arise during the meeting. For example, the marketing person might say, “I like the way they do the login on Dropbox”, so we’ll look at the Dropbox login, and I’ll take a photo of that.
2. Wireframes and Prototypes, Feedback and Internal Validation
Goal: Create a prototype, get internal stakeholder validation
After we capture the sketches, it’s time to create a prototype. One of my strong skills is interaction design, yet I am not a graphic designer, so I feel comfortable with Balsamiq Mockups.
I am always relieved switching from the initial sketches to an on-screen prototype partly because my sketching, like my handwriting, is scrawly. I literally think better with Balsamiq’s clean interface.
Making it Click-Through
I always create clickable prototypes. I’ve already written a post about how I create prototypes using Mockups. Clickable prototypes work best for client demos. Plus, I can conduct better usability testing (see below) on clickable prototypes.
Iterations and Getting Feedback
By creating the first prototype, and clicking around, I will notice some obvious flaws. I quickly make a second version. I keep all versions, so I can show some design variations to the client. After rapidly moving to version 3 or 4, I return to the next workshop armed with my prototypes for internal stakeholder feedback.
Based on the feedback, I iterate again, making simple changes live in the workshop, and, if needed, more complex ones afterwards. Usually after one more workshop, the prototype is ready for usability testing.
5. Usability Testing and More Iteration
Goal: Get external user validation and iterate
If I can’t get real users (people who match the client’s target audience) to participate in the usability testing, I will get proxy users — preferably someone who loosely matches the demographic, but in the end, anyone with a heartbeat who isn’t closely associated with the project. The client will say, “Can’t we just use the developer/designer/marketing person?”.
This makes sense to managers — in the client’s timesheet system, project staff can mark time against the project. I resist these requests. I prefer to take non-project staff, e.g. people from the accounts or HR department. Those closest to the project are heavily biased. What we’re looking for now is external validation.
I review the results with the project stakeholders and we discuss what needs to be fixed in the prototype.
In the best projects, one or more stakeholders will have directly observed the usability testing. I’ve written another, more extensive blog post about my user testing process.
Knowing When to Move On
The design “settles down” after the first or second round of usability testing. first aid vhealthportal.com medicines online. If users seem to be “getting it”, with only minor tweaks required, it’s time to move to visual design.
6. Visual Design
Goal: Turn the prototype into visual design
If the client does not have an in-house visual designer, the client may ask me if I can get the visual design done. Luckily for my clients, I’ve built relationships with a few world-class visual designers, based in Asia. If the client needs to, I try to get one of these designers involved in the project (it depends on their availability).
Selecting the Key Templates
Part of this task is to identify which wireframes, out of all the pages in the prototype, need to be turned into visual design templates. For example, there may be 40 or 50 pages in the prototype, but many will be only minor variations of a previous page. For time and cost efficiency, I identify only the key templates, with unique UI components, that a developer will need.
Iterating the Visual Design
I will work with the visual designer to get the look right. Subsequently, the client will request some revisions. Overall, the revisions needed to the visual designs typically tend to be just tweaks (example: “Make the font size a little bigger in this headline”), not large layout changes.
7. Creating the Front-End (HTML5) Code
Goal: Turn the Photoshop file into HTML5 / CSS3 / Jquery / etc.
Creating clean and beautiful HTML and CSS from good quality Photoshop files is now a lot easier, especially if you use skilled practitioners.
There are all sorts of tools and frameworks, like Bootstrap, or Adobe Brackets, that can help. Again, many clients ask if I can simply provide the HTML and CSS for them and, again, I have some great Asian partners who supply beautiful, clean code that my clients’ developers always love.
Depending on the number of templates, it usually takes around a week or two to get the HTML and CSS files. This is front-end code, ready to be handed over to the developers.
Optional Step 8: Create a High fidelity prototype and Test
On some projects, particularly for software companies, it can be useful to create a high-fidelity prototype at this point. I’ve done this for clients where:
- There are complex or unique interactions, for example an autocomplete dropdown box different to anything found on other websites – and more usability testing is needed
- The client wants to have a shiny, full-colour demo, perhaps for sales purposes
Creating the high-fidelity prototype, using the HTML5/CSS files, for example with custom jQuery, is useful in this cases
Once you create a high-fidelity prototype, the next step is to test it with real users and then iterate it. I’ve used this usability testing on a high-fidelity prototype approach several times for one software house client in particular and it ultimately saved a huge amount of back-end coding effort.
9. HTML5 to Production Code
Goal: Hand over to the development team
Before the client’s development team has written any of the “difficult” code then, they’re getting a beautiful, internally agreed and validated, user-tested front end.
Unfortunately, sometimes my involvement ends at this point. When I say “unfortunately” — I mean unfortunately for the client. I dislike throwing a design over the fence to developers, but I understand that the client sees things in terms of budget: the UX consultant (and his subcontractors) are budgeted for X days.
On every project, however, I try to instill the “user centred design philosophy” in the client’s mind. Because the user’s experience doesn’t end when the product, website or application product is launched. It just begins.
For clients who are more “bought in” to the UX philosophy, what I’ve next is simply…
10. Rinse and Repeat
Goal: Pay attention to your user’s needs, and change the product
In fact, most times, my involvement in a project starts at this point — i.e. when a product, website or application is already live. People who already have a website, application or product ask for my help to “make it more user friendly”. I do my best of course, but when I come to an already-existing project, I’m really doing the same things I do in step 1 above…
- Listen to users and stakeholders
- Observe what’s going on with the site, app or product right now
- Come up with ideas on how to make it better
- Create prototypes and get internal and external validation
- Iterate — make small changes often