Digital Product Crafting : designers and front end developers creating small to medium sized digital artifacts – it’s about building the parts of the systems, it’s not about designing the whole system.

It might be that I’m a crappy designer, but…

I’ve never create something on my own that is as good as something that was crafted with someone else. The act of co-creating gets more knowledge into the design process, gets more idea created and helps better compare the ideas to choose the one to go with. When someone reviews my detailed work they often find things that can be improved or that I’ve missed (I’ve forgotten _the empty state_ so many times this spring). And validating the output together with others create a sense of accomplishment and helps my team mates internalize knowledge about our users and stakeholders.

4 ways to structure co-creation

The classic: JPG file of a Photoshop screen

The designer works alone or with a stakeholder to make something pixel perfect and then sends the JPG to the developer.

• There are no iterations – instead there is a monolithic, static design file.
• Many states and implementation details are missing.
• As a developer I would not feel included as my knowledge of the system and users would be completely ignored.

The current: Sketch + Invision, etc

“At MOBGEN Accenture Interactive, we’ve recently been using InVision suite for the design handoff to developers.” — Lan Belic

• The word “hand-off” says it all – monolithic instead of iterative and the developer’s knowledge is not appreciated.

The close-to-code: Hadron, etc

Hadron is a tool, currently in pre-release beta, where designers can use a visual interface to create web components – basically html and css and js to be shared and reused.

• The designer is still sitting alone doing design work.
• Front end dev environments are usually built on specific templating frameworks and such. Can the web components from Hadron be used in these dev environments and can progressive enhancement / iterative development happen smoothly?

The shiny, shiny future: Nasia, Charlie and Sabrina

I and the three front-end developers in my team do almost all design related stories together:

1. We work together to understand the problem.
2. We ideate solutions together.
3. We choose which idea to work on together.
4. We do some detailed work together, other things on our own. We have different skill sets, of course. But we review each other’s work which often makes the output better.
5. We validate the solution together.

A recent feature

I and Sabrina crafted the “Grouping” feature of the Springer Nature Metadata Downloader together.

We started off understanding the reason why a librarian would want metadata in groups. We also spoke about how the Grouping feature connects to the Filters, Formats and other options in the tool. We spoke to a back-end developer to understand what the librarian would actually get from the server if records where “grouped”. We debated if this feature “splits” or “groups” records. But we realized that it does both.

We explored a handful of options for how the feature could be built to provide the functionality while ensuring excellent accessibility, without javascript and with just enough effort.

We then split up – I wrote the texts and Sabrina worked on the front-end pieces. We looked at the result together, made some changes and then validated the solution internally. After release the feature was also validated with librarians.

Design work should not result in a hand-off

Crafting good digital products requires a process of co-creation. I have the great joy of working this way together with Charlie, Nasia, and Sabrina.