fritzvd

Nelen & Schuurmans, the company where I work, offered the Software Developers a User Interface Design course by Namahn. It was a great reminder of the seemingly obvious processes one can incorporate in a software project, but sadly also a warning for blatant ignorance we sometimes portray as Developers (of course not just at N&S).

The workflow Namahn uses is similar to what other design oriented companies would use. Which can be described in three phases: Understand, Explore and Define.

1. Understand: observing the user and understanding their problem.
2. Explore: trying to find a fitting (the best) solution.
3. Define: defining the scope and spec of the project.

Of course this is already quite hilarious, because as a Developer/Builder of things, it often works the other way around. You build something and show it to some users and hope they don’t have too many problems with what you’ve built. So you don’t have to make too many adjustments. Because, let’s face, it you likely you already blew your budget.

In the course the teacher was met with some skepticism after sharing his workflow at Namahn. One of the reasons for not being able to carry out the workflow is: It’s difficult to do this when you have a deadline, so we rather start with the code.

Which of course is the exact opposite of what you should do. It’s just a natural resort for Developers.

What I take away

What I really liked about the course was the use of paper prototypes and scenarios.

Scenarios of use

What Tom Stevens mentioned about the exploring step was: “words are very cheap at this stage”. So why not take advantage of that fact? Write stories (not use cases which exhaustively explain the functionality) about what and how a user would use the product. Make it fit in with and be of help for their workflow, don’t impose your product in their process. Focus on typical but also on atypical users (e.g. incidental and daily users). A scenario is a story describing a user which needs to get something done. Your product would help her in the process.

Paper prototypes

The second thing Tom mentioned to be very cheap was a paper prototype instead of creating a whole HTML mockup. With a paper prototype you already have to think about how a user would interact with the product and what it should look like. Which buttons go where? What text is useful, what elements of the user interface have no meaning for the user?. You can test it with your colleagues, users or whatever at very little cost. Paper is cheap, and anyone can write and draw.

Below is a summary video shot by one of my colleagues. The video speaks for itself, if you speak Dutch you’ll pick up a little more of what we did.

UI training Nelen Schuurmans from Reinout van Rees on Vimeo.

Conclusion

Maybe we cannot use every little detail of the process that was proposed in the course. But it just shows that you don’t have to have very elaborate and expensive methods to improve your workflow.

P.S. We got mentioned in FastCompany’s article on Dutch Engineering: Against the Tide.

P.P.S. This book helped me think differently about interfacing: Don’t make me think by Steve Krug.