How to code features with (almost) no specs!

I can bet that at least once you were suggested to start coding without any specs, screen definitions or use cases. If it never happened to you yet, brace yourself, the no-specs project is coming.

Apps industry moves incredible fast: sometimes dead-lines gets shorter, your competition released a mind-blowing feature, your metrics are not going so well, etc. All those things generate situations where you and many others have to work against time on a fast, focused and organized way.

I am sharing with you what I do when that happens to me and how I end up with a good experience, a great work climate and optimizing my time.

1. Agree on core features and requirements

Everyone’s main goal before starting doing anything (coding, designing, etc) is to agree on core features and requirements. Always.

To do so, everyone involved (engineers, business analyst, designers and product owners) has to get together and define which are the core features and requirements of the project.

This agreement will never change. It is the heart of the project. If it does, everyone involved should be notified instantly to avoid wasting time.

The key part here is that developers can start working while the rest of the product team can start finishing details, designs, secondary requirements, etc.

Let me present you the use case that I am gonna use as an example.

Use Case: “Mary is a user that wants to see a list of cars”.

Simple, right?

My imaginary stakeholders and I have agreed on this:

• Show a list of items.
• Display some item attributes.
• Use a staggered grid list.
• Access to a filters screen from the listing.
• Track some events.

2. Forget about the UI details

Details are a very important part of apps development but when the time is a scarce resource then you better start coding a simplified UI.

The secret is to forget about details.

You should identify core UI components and interactions.

For example:

• Buttons.
• Input fields.
• Custom views to implement.
• Screens navigation.

For the listing example, I imagined this simplified UI:

Simplified UI sketched for the listing sample app.

Basically, I have identified the following: a filter button, a grid view of items, basic items’ information to display and some extra information to show about the listing.

3. Implement core features and requirements

As you already have the core functionalities and requirements and a simplified UI, you can start coding it and all the technical tasks that are specific to you work.

At this point you should focus on things like:

• Connecting to the back-end service.
• Code the simplified UI.
• Solve integration problems.
• Data persistence.
• You name it.

Going back to the example, I am going to focus on: retrieve items from the server, add logic for pagination, implement a staggered grid list, create the model classes, navigate to filters screen, add tracking events, and so on.

All that resulted in this:

Partial implementation of the listing sample app.

4. Implement the design & details

All your previous effort has a purpose, remember? To optimize the team’s time!

• You were able to start coding a feature with (almost) no specs and start solving integration issues.
• Design, UX and Product teams (and you) had time to define all the details of the project.

So, now it is time to implement all the details that you were postponing.

That would mean:

• Add animations and transitions.
• Add secondary actions.
• Apply design specs.
• Add more tracking.
• Etc.

In my case it resulted in this:

End result of the listing sample app.

Don’t forget to keep talking

My last recommendation is: keep talking with everyone involved in the project (designers, product owners, business analysts) during the entire process.

Get updates, validate, show progress and ask for and give feedback always help to do a better and easier job.

Also, sitting close to the proper stakeholder while I implement each part of the project (design, product behaviors, tracking) helps me to have less bugs, re-work and frustration.

In the end everyone wants to have a killer-feature live!

Note: Dami Buonamico recommended me an article by Mike Cohn called “An Iterative Waterfall Isn’t Agile” and I encouraged you to read it too.

Did you like what you just read?Recommend this story (by clicking/tapping the ❤ button) so other people can read it!You can also react on Twitter: @santihollmann