I'm working on a new website for my freelance UX design company. One feature that has done very well with usability testers so far is a new section of the site explaining my design process. Testers mentioned that this really sets my company apart from other design companies they have seen and it helps ease their concern that I have had fewer client projects than most other designers.

My process, which is based on projects I've done for multiple clients in the past year and a half, goes like this:

  1. Understand users
  2. Evaluate usability/design of existing site (heuristic evaluation)
  3. Initial user test
  4. Open and closed card sorting
  5. Brainstorm and sketch
  6. Select a theme (text: "We select a theme that will let the site look great on any device. We look for themes that allow extensive customization so that the site looks like yours, not someone else's.")
  7. Wireframe
  8. Prototype and customize the theme (iterate on 5-8 as necessary)
  9. Prepare for launch: "We work with developers to help our vision for your site become a reality and perform as well as it can. Bringing our previous development experience, we understand what can and can't be built well."
  10. Go live

With average users doing the rest of the tests on my company's new site, I had one more senior UX designer test it. (This was on purpose. Since I've never been part of a larger UX team, I was looking for a design review.) His feedback was very helpful. Two of his questions really got me thinking about my process:

  1. Why step 6 (select a theme)? It sounds like you're just going to ThemeForest, which won't necessarily give me the best possible result. (He's right about going to ThemeForest, though I've customized themes so extensively that the original theme is hardly recognizable.)
  2. Why would you create wireframes if you're using a theme?

For my clients, customizing themes has worked well so far. But in my industry, clients' sizes, budgets, and customization needs vary quite widely. Some need a team of developers or, at least, one developer doing full-stack development work. Doing full-stack dev work myself isn't an option for me and doesn't seem cost-effective.

Currently, I don't have the budget to hire a developer. Potential future projects, including some longer-term ones with bigger teams that are probably another 1-2 years out, may give me the chance to hire contractors. But without any projects on the horizon that look like they will definitely need this, I can't say yet how the development step will definitely be handled.

If you were in this situation and writing about each step of your process on your company's website, how would you address the development step?

Edit - On some of the theme customization projects, I worked with the client's in-house webmaster / back-end developer.

  • 1
    It sounds like you focus on UX Design (which is great) but gloss over visual design (which isn't so great--per the feedback you got). I'd just omit saying anything about 'themes'
    – DA01
    Apr 4, 2014 at 18:02
  • 1
    In general, if you are solely focused on UX, it'd be better to adopt a 'we partner with...' model for things outside of UX. So partner with developers from day 1. Partner with visual designers from day 1. Partner with marketing, etc...
    – DA01
    Apr 4, 2014 at 18:13
  • After sending an answer, I read the "Looking for an answer drawing from credible and/or official sources." (I should have done it before), so I was going to delete what I wrote since it doesn't provide any reference, but then I was thinking on your question and I don't see how to mention studies or research about that. So are you looking for research on the subject or answers based on personal/company experience?
    – PatomaS
    Apr 8, 2014 at 7:09
  • @PatomaS I'm looking for answers with some of both. I'm a one-person shop and looking to see how everyone else here (whether in larger companies or not) would handle a situation like this. Published/official sources would be a big help.
    – David
    Apr 8, 2014 at 17:09
  • 1
    Looks like step 7 (wireframe) should go before step 6 (select a theme) and you should have a software architect involved in step 5 (brainstorm) instead of waiting for step 9 to see what can actually be done and then potentially going back to step 5. Apr 10, 2014 at 13:54

4 Answers 4


Answering this question is hard because we are not you and we don't know what you do and how, so assuming that the steps you posted are the steps and order that you follow, then that is the right answer.

But, less assume that you want to change that aspect of your communication with your clients, not necessarily change your steps, although a little change would be great.

First lets tackle the problems with what you posted.

For steps 3 to 5 I'd ask, of what? grammatically, it says that you are testing and investigating the existing site from the user perspective to complement your personal expert opinion, is that so? If it is, then a little longer explanation would be good so there is no possible misunderstanding. Then you would have to repeat those steps later with the wireframes of the new site, otherwise, you are stating that the original design may have problems but yours doesn't and that what you do is exactly what users and stakeholders want, which sounds arrogant or irresponsible.

Step 6, in that position is wrong on many levels. First states clearly that you don't design, second that you copy (even if it's just as a base design), third that you have no idea what is the relevance and use of a wireframe and prototype, which most probably is not the case since you mention them, but then it can be seen also as that you are just using them as buzzwords that you don't understand and that's why you put them in the wrong order, for users with zero understanding it may be OK that way, but for clients with a little bit of knowledge, it may sound bad and it may reduce their confidence on you.

If the creation of the aesthetics and design of the site is something that you want to make relevant to your clients, do it but in the right position, after you have done the wireframing and tested it. If it's not relevant because you focus on usability, accessibility and/or UX, then leave it out from that list and mention it later. For instance separate the information in sections, one section for the Information architecture of the site and another one for the design.

Steps 7 and 8 should not be after selecting the theme, the theme has to adapt to the needs of the site, which has to adapt to the needs of the user and stakeholders.

Steps 9 and 10 are OK, although you don't mention any post launch analysis, may be you don't do any, and then you are honest; in that case, you should start doing it. If you do it, then don't leave it out of the list, is one of the most important aspects to remind the client that you are there to help them get the site working properly, not that you are going to abandon them as soon as you can.

After that long but not too deep analysis of your steps, lets see how you can adapt those steps to better help you user, and may be yourself. I'm considering that you already have enough experience to decide what is a good starting design for a website, and flexible enough to adapt it to your clients and his users needs.

  1. Interview users.
  2. Analyse usability of the existing site.
  3. Analyse design of the existing site.
  4. Present conclusions and options to the client.
  5. Design a wireframe
  6. Test the wireframe with users and stakeholders.
  7. Adjust the wireframe and generate final prototype.
  8. Create the visual design (This, obviously, happens together with step 5, but as a separate item looks like you are doing more detailed work, which is also true).
  9. Implement the visual design and fuse aesthetics and functionality.
  10. Launch.
  11. Post launch analysis.
  12. Fix or adjust details.

Those steps don't cover everything and the text is not final, but gives you an idea of how to write the process from a UX perspective where you don't mention details that are not relevant to the client, like choosing a theme instead of doing original design, but gives the right weight to select and test things for the benefit of the final user. It's also a similar process for the development fase, you can mention that you can work with their team. But you have to make very clear that you don't have much development or designing capabilities, not because you don't know the area, but because you focus on a different one.

Of course each step can be explained with as much detail as you want on your site, giving the client the option to really understand how each step works and how it relates to the whole process.

You also should mention somewhere the burocratic process, like payments, way of communication, expectation of input from the client, timing for deliverables, etc, but that can be on another section of your site. I'm sure that would also be a good thing for your clients and you since that stablishes from the beginning the way you are going to interact with them.

All the above mentioned is similar to what we use to do in our company, although we don't have that explanation online now while we are transitioning to a new design. We had a page about the interaction with the client that was like a timeline to show the evolution of the process, one page to talk about design specifics, one to talk about analysis and tests and one just to explain the relevance of the content that the user has to write/deliver.

  • Thanks. Your assumption on steps 3-5 is correct. The process I posted was only high-level. Here's the full process page, currently in prototype: nl5tjl.axshare.com/process.html. (Please disregard the visual design. I've now started another iteration based on user feedback and it's going to change a lot.) I do multiple rounds of user testing throughout the process. And there's also post-launch analysis and support. How much of each depends on what clients can afford, but it is there.
    – David
    Apr 8, 2014 at 17:29
  • Also, designing is one of my focal points. When I say that I use themes, the themes I choose tend to be minimalist themes that allow a lot of customization. I use plugins to expand those customization options. It's mostly to reduce my debugging work (and save the client money) by providing a starting point that has a lot of the technical capability built in. When I customize the theme through visual design / HTML / CSS, the sites I produce become unrecognizable from the original themes. Most of my clients already use WordPress, so existing themes or child themes are a deliverable they expect.
    – David
    Apr 8, 2014 at 17:33
  • Nice feedback! +1 :-) Apr 11, 2014 at 10:06

Since you are a freelance person. Developers are involved at the planning phases each of your steps: 1, 3, 5,6,8,9, 10.

The clients must approve your designs before the developers start implementing the design to code. During the planning process, the developers will be able to estimate how long the development would take place once the Clients have approved the design.


Your question is a bit vague.
First you ask "how to describe dev.step", then you ask about our process. On top of that you raise a few issues during your background description.

I have some comments, answers and questions that might be helpful.

1) Who is your user group?

When you want to describe your process, you need to understand that this is not a CV or a job application or an examination answer. You are describing this to your potential customer. Thus you need to think about what they want to know, what they need to know, what you want them to know.
This is really important!

You have thrown a senior UX designer into the test. Are any of your customers "fellow designers" that knows about wireframes and what you mean by "select a theme"?

Or are your customers "end users" that runs their own coffee bar or their own thrift shop? That's a big difference right there. The cashier might consider "theme" to be the visual tone of the site (retro, modern, flower-power, princess, pirate), while the fellow designer would think about WordPress themes.

2) What's important for the customer?

I can assure you that most customers are concerned about the overall cost of the work. While we will argue that "a proper job must be carried out", the end user will have some budget or limit they need to keep in mind. When they look at the process you describe, they would probably want to get a rough feeling about how much time you spend on each step, and they would probably use this to track progress.

The customer would also like to know where in the process they are involved and where in the process they can see some results.

3) What's important for you?

For your sake, it is nice to be able to point the user to a description of the process. Make it clear for the end user what you will do, so that you wont enter some arguments about what's necessary to do in the process.

This will also work as an implicit state and progress report.

4) The simplest process ever...

I love the waterfall model for it's simplicity. Even if the strict waterfall process isn't suitable for running projects, it very nice for simple explanations:

What should we create -> How should we create it -> Create it -> Test it

5) How to describe "development"

I don't believe it's necessary for the customer to know whether this step is outsourced or not. They just want to know that it's properly done.

In general, I believe "development" it self is explanatory, but you could use terms like:

  • Implementation of features
  • Customization of functionality
  • Let's create the god damn thing

Bottom line:
Step into the mindset of your customers and figure out
what they want to know and
what they need to know...

Be sure that the explanations are in the language of the customers.

  • 1) No, my customers are not familiar with wireframes, prototypes, etc. I work on UX design in an industry where it really hasn't been done before. My prospects tend to be marketing directors/managers at mid-sized companies or owners of small engineering/manufacturing companies, all within that one industry. Many of them have spent most or all of their career in that industry. ... 2) Cost is important to many of these prospects. I am planning to have a section of the site for laying out why people should invest in UX design. ...
    – David
    Apr 11, 2014 at 17:10
  • 3) Agreed. I plan to also include this process in my project proposals and point to it when necessary. ... 4) I see 2 main problems with waterfall. First, design is iterative. In each iteration, a designer can only hope to be "wrong in the right direction". (I saw this in either A Project Guide to UX Design or About Face 3. I can confirm it in my past projects.) Second, people in an industry unfamiliar with UX sometimes don't give feedback on wireframes or prototypes. A recent client only gave feedback on live beta sites. When making their requested changes, I still followed my process.
    – David
    Apr 11, 2014 at 17:14
  • 5) Development (or web development) is a term that my clients and prospects understand. My largest competitor is a web development company that does much of their work in my industry. They are very feature-driven/-focused in their website copy and don't really discuss user goals or UX. They've worked for a lot of the big clients in that industry and are pretty well-known in the industry. A lot of other companies in that industry hire their local design companies.
    – David
    Apr 11, 2014 at 17:18

I just want to address the part of your question that revolves around describing development.

It will always be 'Bringing the intended to life'. If you follow that chain of thought you could describe it as 'translating functionality and aesthetics into code'. This statement gets the most singular interpretation in my experience. It is intended to replace step 8 of your process. Themes do exactly that, as will your future stack of developers or contractors.

I do not want to say 'translating design into code', I prefer to mention aesthetics & functionality as it is the result of the design process.

Even though you use themes, as your business grows you probably wont be if you follow the path to cultivating a development stack. And either way, in the foreseeable future if design is easier to implement, you would still be 'translating aesthetics & functionality into code' when you enter the development phase.

To make it all come together consider describing step 6 as 'Visual Design'; As suggested by a others who have answered this question.

The language you use needs to be dynamic in its ability to deliver a message that adjusts to the scale of your operations whether big or small.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.