What is the best way to design and implement new features for our website editor? This article provides some insight into how we work the “collaborative creative way” based on the example of our new column feature in the Sites editor.
Our development teams have been agile for years now. But what about the people who conceive new features and write the user stories and tasks for the scrum team backlogs? When a new feature request comes up, we always try to see it through the eyes of our end users. It is important to formulate this request as neutrally (and non-technically) as possible. In this case, it was very simple: “I want to be able to format text in columns.”
The first step was to put together a project team consisting of some of our non-technical co-workers and some developers. All of them were invited to a creative meeting, but everybody had to do some research in advance. The research tasks were finding good-looking websites with columns, finding out how other (word processing) systems solved this problem, and summarizing the technical implementation options.
During the creative meeting, everyone gave a (short!) presentation of his/her personal research results. Afterwards, we were all on the same page when talking about ‘columns’—which does not mean text flowing from one column to another like in a newspaper, but instead fixed text blocks that look good on all devices in our responsive world.
We then started wildly brainstorming about how we could satisfy user needs in our website editor. A number of crazy ideas came up—all of which were written on sticky notes and put up on a big whiteboard. During this brainstorming session, we came up with some very good solutions and agreed on one that no one could have imagined alone.
The next step involved some craftiness after the meeting: We printed and painted the discussed solution, glued it, and—voila!—our first paper prototype was ready! We took this paper prototype, and we visited a number of other (previously uninvolved) colleagues and asked them to test the feature (the mouse was a wooden stick). Most of them liked the prototype, but there were three or four specific suggestions for improvement. We optimized the paper prototype until most people liked it and put the implementation task on the backlog of the scrum team involved based on this prototype.
When the team started implementing the feature, it became clear to everyone that we needed to do another usability test as soon as the feature could be tested in a browser. Again, we asked some of our co-workers from various departments to format their website text into columns. The result of this second-phase usability test was very positive: All of them had nearly the same user experience. Many things went well, but, as usual, some didn’t. So, we had another meeting with all of the people involved, where we figured out that all of the ‘problems’ were related to the same issue. We decided to eliminate this part of the implementation. A final test and implementation phase followed. Again we let new people test the feature and asked those from prior tests for their feedback.
From our experience, working this way is a lot of fun and involves a lot of interaction with the developers. This method requires a lot of preparation, a number of well-moderated meetings, and the need to talk to many people to find testers. On the whole, it must be said that the level of acceptance among end users—and, of course, ourselves!—is very high for the features implemented this way.