I’m no designer. I don’t aspire to be one, nor do I claim to be one that; however, I am interested in the topic and enjoy seeing the work that others do as well as following blogs, articles, books, etc. on the topic.
Though user interface design is a bit of a different field, it hits much closer to home for me than other types of design. After all, a user interface is basically the face of the code that we’re writing.
And if we’re not careful, then we’re going to continue perpetuating the stereotype that developers do not care about design.
I’ve spoken previously about sharing case studies on WordPress projects, and though I don’t have a full project to share right now, I thought it might be fun to look at some I’ve been working on and the evolution of a particular user interface that evolved from a first pass, to discussion, then from mockup, to implementation.
A UI Design Process For Project Volunteers
I’m currently working on a plugin for someone part of which allows them to select volunteers and and assign them to projects.
At a high-level, one feature of the plugin does the following:
- Introduces a new “Volunteer” user role
- Allows the user to assign and remove volunteers from the application to specific Projects
Naturally, I have to account for the cases when volunteers are already assigned to Projects so they aren’t made available, and I try to limit the user’s options based on the status of the selected volunteers
The First Pass
The first pass of the user interface included a multi select element that allowed users to hold “Command” or “Control” and select each person that they wanted to assign to each project.
It’s functional for a first pass, but there’s a lot of room for user error. In fact, here’s a bit of the feedback generated from the first pass:
I think the current version could lead to accidental volunteer removal. Click on a name in the volunteer area and all other names are now deselected, and if you hit save everyhting is lost. Imagine that happening with a list of 100 volunteers and 30 people helping. That would be bad news.
Good points, right?
So I came up with a second pass using Paper that looked like this:
After receiving the feedback, I sketched out the above mockup then passed it back for review.
Ultimately, the UI would work like this:
- All of the volunteers in the application would be available on the left
- You can select one-to-many and assign them to the Project
- You can also remove Volunteers from the Project in the same way
After getting the sign off, I implemented the following UI:
The UI In Action
Finally, the implementation of the user interface can be seen in the following video:
Overall, it’s simple enough, but this goes to show why having small feedback loops and roping clients into testing various iterations on individual milestones matter.
It helps to create a product that not only works more inline with their vision, but also exposes things that you – as the developer – may not notice simply because you think like a developer, not a user.