My UX Process
6 Steps of a UX Design
My fascination began when I watched a video of Alan Kay explaining the PARC user interface during a Stanford lecture. That was 4 years ago now, and for the last 2 years I have worked hard to improve the usability of SmartDraw. My work flow looks something like this:
- Collect the facts and brainstorm
- Make a static rapid prototype
- Perform an initial test with a small number of people
- Pick 2 designs that get best feedback and create interactive prototypes
- Test 2 designs with current users and non-users
- Review results and create spec for the developers
Your process may differ from mine, but regardless of the workflow there is one common breaking point; people. When it is just you, you don't have to worry about communicating or delegating. You just do want you know to do and get it done. The moment you introduce marketing, sales, support, and executives into the mix, the need for communication (and therefore process) becomes imperative.
When communication becomes imperative, I find that graphics get the message across better than text. A bullet list always seems to lose some of the connections found in "brainstorming", and a paragraph never paints the picture of a new UI or website the way a rapid prototype does.
Communicating Through Images
We have all heard the phrase "a picture is worth a thousand words," and we use prototypes and wireframes to make our ideas tangible. So why on earth do we resort to lengthy explanations and bullet points when we need to communicate with others? Each step in my design process includes some kind of graphic as part of the process and process is really just a form of communication right? Try rewriting your process in terms of a graphics, mine would look like this:
![]()
I encourage you to try replacing some of your bullet lists with graphics. You will be surprised at how much easier it is to communicate. The next time the head of sales wants to know when "feature A" will be completed, show him a static prototype and a project chart displaying the time frame. Or the next time you need to explain the spec changes to an engineer so they can write the code, try a mind map and state diagram. If you use graphics, you will spend less time explaining, get less frustrated, and get more done.
Collect the Facts and Brainstorm using Mind Maps
Every time I approach a UI problem, I start with a mind map and do a little brainstorming. In the center I write the problem I am tackling. For this example the problem is connecting objects with lines.
For every variation of the problem add a topic which connects back to the core problem. Here I add a new topic for connecting steps in a process and a manager to a subordinate.
The variations could come from user test results, tech support issues, feedback from sales agents, anything that represents a problem related to the central idea. When you can't think of any more variations, begin adding sub-topics off each of the problem variations. These sub-topics could be a solution, a bit of research, a customer suggestion, personal ideas; anything that provides a solution for the connected problem variation. I add sub-topics for a new connector tool, a hyperlink to a user test I did, and a comment made by the support manager.
Once you have mapped the problems and solutions, look for commonalities. Are there solutions that appear more than others? Can a solution for one be a solution for another? That is what I look for, a couple of solutions that I can mock-up in a rapid prototype or wire frame. For this I would spec out using the keyboard to add shapes, and create a couple of prototypes for how it might look on the screen. If I had done this in a bullet list it would look like this:
The bullet list works ok when you have a very small number of variations. In the real world you could have 10-15 variations, which would translate into a 4-5 page bullet list. Not exactly optimal, wouldn't you agree?
