Smart production flows
How to build your product faster, increase quality and improve user’s happiness.
I’ve been building apps for almost a decade now, from humble beginnings with the old and crappy JavaME to now, with the zillions web frameworks available and powerful native implementations.
We’ve evolved a lot since the first bulky connected Nokia phones. Now we’re harnessing more computing power out of ever smaller devices. These improved experiences enable us to fawn over users attention with improved usability and a cleaner, cuter design. The handling of all of these new demands is a never ending exploration of cutting edge techniques.
This is an attempt to describe an set of efficient practices, optimized flow in order to attain flawless execution while building a digital product.
The Success Equation
I’m an engineer, so I love equations:
A = E + D + U
Where A is your final App, E stands for engineering, D for [graphic] design and U for usability.
This simplistic representation lacks the team effort factor. It symbolises the achievement as a simple sum of three distinct efforts. Three isolated silos that only communicate though their own deliverables.
If you manage your project that way, even with agile-scrum-whatever-trendy-management-buzzword you can place there, you are doomed to fail. Fail because your haven’t acknowledged the strong interaction that exists between those three fields. We’re not building layer cakes, but a real homogenous sauce.
Now if you consider each field can be an input to the other, we can use that more accurate equation:
∫ E(D,U) + D(E,U) + U(E,D) = AAA
You wanna make it Triple A, that’s how you do it!
That’s a pretty complex equation, and you can’t algebraically solve it. As each function depends on the result of the other. Synthesizing it that way gives a better understanding on how complex executing great products is.
No good engineering can be done without the knowledge of design and experience. No great usability can be achieved if there’s no knowledge of the feature set, target platforms, technical restrictions and freebies. And finally the awesome design you’re cooking is worthless if it doesn’t take into account the rest.
And remember that:
Great engineering is invisible.
Great design is invisible.
Great usability is invisible.
The almost great way
I’ve often met with clients in the past and applied a very waterfall approach. Do the UX, sign the UX, do the Design, sign the Design, build it, deliver it, start over because something doesn’t work with the UX.
Even if each of the silos are agile, that doesn’t your whole organization is Agile. You end up with a sum of fast iterative phases instead of parallelizing knowledge and execution.
And that sucks. Really, just because we never thought to ask the engineer what he really thinks about the UX more than 10 seconds, we end up with crappy products, increase the number of bugs, lower the quality.
We can’t ask a usability expert to know all ins and outs of the mobile development, nor we can ask a designer to know everything about user experience.
In fact, all of those are interdependant, but only fot the final deliverable. All along the process you could have development going while moodboards are being made and while the usability people are refining the experience.
Get Florent Vilmart’s stories in your inbox
Join Medium for free to get updates from this writer.
Do you really need a 50 pages detailed wireframe to start designing? Not really. You don’t even need one page of wireframes. The designer can start thinking in terms of reusable and testable elements: button shapes, fonts, color arrangements and schemes, reusable patterns etc. One should be able to paste the design on the wireframe not spend hours in making the wireframe beautiful. As a developer, we don’t really need to see a fully beautifully rendered app on Photoshop. Developers need to be able to quickly extract color schemes, font sizes assets, vectors, not spend hours group naming, versioning… That’s even more true now with the zillions of render size that need to be supported. Let’s just take the iPhone example, we now have 4 different screen sizes and 3 resolutions depth. The only way to build the most optimal app for all those sizes is to have a thoroughly though UX.
The Better Way
All along the process, every production meeting should involve at least one person of each area of experise.
KickOff
The kick off meeting is maybe the most important one. It’s agenda should consist the following two
- Discuss the technical features and identify the challenges
- Discuss the global interactions architecture, usability patterns.
- Define the first list of achievable goals for each fields.
During that kickoff, draw a lot, discuss a lot, ask a lot. The goal is not to have the full architecture but to share comprehensible knowledge across all fields.
After the kickoff:
- Designers should be able to start drawing mood boards, common buttons, visual effects.
- Engineering should be able to start their software architecture, anticipate the bottlenecks and risks, start test driven development with all the core mechanics of the app.
- Usability experts should be able to standardize the user interactions, product wireframes for the first screens.
With that process, each field is one step ahead of each others. Nobody’s sprint got bottlenecked by a deliverable.
Depending on the size of the teams, it’s important that while decisions or reviews are being made, those reviews are fueled with every fields point of view. That will help prevent or defuse any bad practices, black holes, or other overly time consuming tasks.
To help with that, and in respect with great team spirit, it is possible to assign sprint experts per speciality. This ‘expert’ would be the reference for meetings, can properly communicate back to his peers in the proper language.
Accelerate
The execution phase can now start as the proper frameworks and team communication are in place.
As everything never goes according to the plan, the presence of all fields at team sprint definition meetings will help reorganize each other’s work so the first sprint’s advance is not lost.
Deliverables
Each field have it’s way of doing stuff, but I still hate designers when they provide non comprehensible files with lots of non exportable effects.
With modern tools, it is possible to streamline the design / export / integration process, that should be taken into account.
It is pretty simple to identify what should be delivered. Think that:
At any moment in time, anyone in the project should be able to use your by-product with zero to little knowledge
That means for example:
- Apps available on beta testing servers
- master repositories that build
- properly cut/named/sliced PSD’s
- wireframes exported in PDF format
Hell, you should write enough documentation for designers or usability experts to run and test the app.
And all of those should be accessible at all time, anytime by anyone related from close or far from the project, for quality insurance, review, comments etc…
Remember the function earlier exposed, if you remove the ability for the engineers to review/comment over the UX, you’re killing the UX function itself but also the engineering and the design.
A digital product, like an app, is a complex system that involves the result multiple fields of competence interacting with such precision that it makes each of them disappear under the user’s wonder. The failure in a single field of execution will make disappear all efforts and magic being delivered elsewhere.
