Interaction Design Process

Open Source software typically has very few people focusing on the user's experience. This is a difficult problem to solve, and perhaps the best way to approach it is to encourage developers to start thinking about the user experience of their software projects.


After my time working with Fedora Hubs was complete, I was offered the opportunity to present on my Regional Fedora Hubs design project at Flock 2017 in Cape Cod Massachusetts, USA. I decided that the best way to approach the presentation was to offer non-UX folks structure around bringing UX to their own projects.


In addition to summarizing my work in the presentation, I created a handout to guide my listeners both during the talk and for later when they might want to do some interaction design of their own. For those who might be interested, the video of the presentation on Youtube.


I found it easiest to explain my process according to the graphic above: an iterative process involving research, analysis, and design.


In all cases, start with research. If it's for a new product, research into what folks are doing around the problem space right now, what competitors are doing, whatever the new product depends on, and conversations with stakeholders to identify their needs. (cell A)


If it's an existing product, research should include competitors, looking at how your existing users are using the product, information from support and sales, and any other related stakeholders. (cell C)


Once one has some data, the next step needs to be analysis: what did we learn from all that data, how do we interpret, prioritize, and address the problems people are having? Sometimes this analysis will show you areas that need more research. This may block you, but it may not. (cell D)


Next, look at design: do some sketching and then make digital mockups of the ideas you and your team came up with during analysis. Visual artifacts are very useful to identify areas where things can't work the way one thinks, as well as to make sure everyone on the team actually agrees on what to do. Sketching is great to help one think through the possibilities with as little cost or time as possible, and mockups are helpful for sharing those possibilities. (cell G)


And then it's back to research: Visual artifacts also offer an easy way to get some feedback (criticism) from others on your team, since no one's design is perfect, and additional perspectives are invaluable. Make sure to talk to various stakeholders about the mockups - developers and designers alone can have very different ideas of what's possible or reasonable, and other stakeholders may also have useful insights. (cell B)


Use the feedback you got from the folks in your company or team to iterate on your designs. Their input will help you see things you missed or entirely forgot about, and that's the cheapest and quickest way to handle some of the basic problems inherent in a single person's viewpoint. (cell E and H)


After feedback from within the company or team, the next step is to do research with potential or actual users or customers. This doesn't have to be hugely complex - there's even something called guerrilla usability testing. However, if you are dealing with a very specific, highly technical, or highly trained user set, you will need to make sure to include potential users. People who are not your expected users will have different goals and needs, and the further your users are from a typical person, the more important it will be to have the correct people testing your prototypes.


One of the most common usability testing methods is to create a prototype from the mockups one has been working on, and ask users to do specific tasks with those prototypes. Prototypes can be as simple and low-fidelity as paper, can involve low-fidelity digital artifacts (like you can get in MyBalsamiq), or you can use higher and higher fidelity up to and including quick coding. (cell B)


Use the information you gain from your usability testing analysis to identify the areas that need the most work, preferably with other stakeholders or team members. (cell E) Take that information and continue iterating on your designs. (cell H)

Caveats and notes

Be careful with fidelity: the higher fidelity an artifact is, the longer it'll take to create, and the more likely that people will be attached to those ideas.


It's best to start low fidelity and increase fidelity as one gets a better handle on what is and is not working for your users or customers. This allows you to get external feedback early on in the design and development process, thereby reducing the time spent on things that don't actually work well for the users. (The Nielsen Norman Group often has useful information on user experience, including on the fidelity of prototypes)

As in any aspect of software development, you will need to make the call about when your software's user experience is "ready enough". Using user testing and getting design feedback from your team before you write the code will help you find the biggest obstacles for your users.


You may have noticed that the chart above does not include anything about aesthetics, or visual and graphic design. These are not my skill areas, but are important to the overall experience of your product. If your team or company has style guides or pattern libraries, these can make it easier to make good decisions about aesthetics of your product.

© 2019 by Suzanne Hillman.


Created with

(617) 275-3466

  • LinkedIn Social Icon
  • Medium Logo
  • Twitter Social Icon
  • Github