If I am not the developer and I haven't hired one, how should I explain the development step of my UX design process to potential clients?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.